# 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.