Introduction
Normally we just locate the HTML_Element in HTML_Document::MouseAction
and send the event to it through FramesDocument::HandleEvent, but then
there is scrollbars and all kinds of form widgets to complicate
matters.
Element types with special handling
Button types (<button> and input
type=button,submit,add,reset,remove,move-up,move-down
These are to be treated as normal HTML elements visavi the document
events, but with a couple of exceptions. First, a button becomes
"active" by pressing the mouse down in it, and any mouseup on it
should result in a click. Alsp, even if the mouse is moved out and
then in again, it should still click it. To make the button draw
correctly, it might have to know about events happening outside
it. While <button> and input buttons should act the same for
the user, they're very different to us since one has a FormObject
(inputs) and the other has only a hidden OpWidget.
Checkboxes and radiobuttons
These works as buttons, but the value should be changed before
onclick and restored to the original value if the onclick event is
cancelled.
Text types (textarea, input type=text, type=number,url,email....)
These capture mouseevents after a mousedown to be able to handle
text selection with a mouse. No events should be sent to anything
but the control.
selects as a listbox
mousedown on a option should result in a onmousedown event to the
option. After that the select box should capture all events to be
able to handle drag selection. A mouseup on the same option should
result in a mouseup on it and an onclick on it. A mouseup outside
the listbox should result in a mouseup on the select, and no
onclick.
selects as a dropdown
The dropdown should be handled as a button, but it should open on
mousedown. When it is open, a click on an option should result in a
onmousedown,onmouseup,onclick on the option element.
scrollbars
Many widgets have scrollbars, and even normal html element may have
scrollbars (overflow:auto/scroll). Whenever a scrollbar gets a
mousedown it starts capturing mousevents and no events should be
sent to the document tree.
disabled elements
Form elements can be disabled with the "disabled" attribute.
If a form element is disabled, it should not receive
the dom events onmousedown, nor onmouseup or onclick.
Internal state
To our help we have a couple of different pointers:
OpWidget::hooked_widget (also known as
g_widget_globals->captured_widget)
This is a widget wanting to know
about all mouse events.
active_html_element (not to be mixed up with the local variable
|active|)
This the element to got the mousedown and is "armed" for
a mouseup which will trigger the onclick. Any mouseup elsewhere
won't cause a onclick.
captured_widget_element
This is the form element capturing mouse events.
last_mousemove_x, last_mousemove_y
Global variables with the coordinates of the last mousemove event.
Communication with elements
Communication directly with a widget is done through
OpWidget::GenerateOnMouseLeave, OpWidget::GenerateOnMouseDown and
OpWidget::GenerateOnMouseUp. These might have side effects if they
have widget listeners.
Communication with form elements are done through
FormObject::OnMouseDown, FormObject::OnMouseUp and
FormObject::OnMouseMove. These also talk to widgets and might have
side effects (such as sending dom events).
Normal events and elements are called through
FramesDocument::HandleEvent.
DocumentEdit
In document edit mode, we intercept all mousedown events to avoid
triggering actions and instead we use mousedown events to position
the cursor.