[PATCH] Last version of the "fix label form focus" (59489)

[bj at altern.org]

> Using the activate event is not complicated at all.
> We'd just have to replace the synthetic CLICK_EVENT for a synthetic
> ACTIVATE_EVENT. Since an activate event is generated during the CLICK_EVENT
> handling anyway, it's even simpler and will have less side effects.

Problem: currently, radio buttons and checkbox react on the MOUSEUP_EVENT.
This is needed, because if you have some javascript, for example: 
 <input type=checkbox onclick=javascript:this.checked=true>

It is important that the HTMLInputElementImpl::defaultEventHandler is 
triggered before the javascript event.

The MOUSE_UP event is sent before the CLICK_EVENT, so it works.

If you react on ACTIVATE_EVENT, the javascript will be triggered first (see 
dom_nodeimpl.cpp, line 405: dispatchGenericEvent), and it will not work.

> > I'd rather advocate a dumb approach
>
> The dumb and IMO more correct approach would look like this:
> When an accesskey of a label is pressed, let HTMLLabelElementImpl react on
> this by
> 1. setting focus to the form element,
> 2. sending an ACTIVATE_EVENT to the form element.

In my opinion, there are only two options for accesskeys:

1) When pressing an accesskey, you just focus the element.
2) Pressing an accesskey behaves exactly as if you clicked on its element.

I would prefer 2) since the aim is to make navigation easier and faster.
The W3c recommandation, says that  accesskeys "focus" the element, but later 
they say that an accesskey for a link should activate the link.

> > So an obvious solution would be to dispatch a MOUSEDOWN, then a MOUSEUP
> > then a CLICK from there, so that the logic doesn't need to be changed at
> > all.

I agree with this, as it seems to me that it is the only working solution.

> It is wrong to issue the click. It can't be improved by putting more wrong
> code around it.
>
> If an activate event reaches the default event handler of
> HTMLInputElementImpl, it will do exactly what you want: Submit/reset the
> form, check a radiobutton or toggle a checkbox.

No, since the default handler for checkboxes/radioboxes reacts on 
MOUSEUP_EVENT, as said before.

> Additionally, we'd avoid all side effects that arise from the click().
> Otherwise the accesskey handling can interfere with every piece of code
> that is supposed to react on mouse clicks. Such code exists in khtml and on
> the web, e.g. an attribute ONCLICK="return false" in a parent node of the
> form input would defeat the accesskey-functionality completely if we use
> the click()-approach.
Accesskeys are especially useful for people who cannot use a mouse, so I think 
they should trigger exactly the same events as clicks.


regards
Jean-Baptiste