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

[Tobias Anton]

On Donnerstag, 8. Juli 2004 16:06, Germain Garand wrote:
> > Basically, that's a good idea. But it would still be better to react on
> > the activate event than on the click event.
>
> As much as I agree, I don't think it is a good idea to do that change right
> now. There's nothing fundamentally broken with the simulated click approach
> and we are at a point where we should strictly focus on bugfixing.

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.

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

> The dom HTML spec says the HTMLInputElement::click() method should simulate
> a full blown mouse-click on the element - it doesn't say it should dispatch
> a CLICK_EVENT.

The spec, however, does not say that a label should invoke the method 
HTMLInputElement::click() at all.
It says that "hitting an accesskey gives focus to the associated element" and 
"when a label receives focus, it passes focus to the element referenced by 
the for-attribute". No click mentioned there.
But I assume that the phrase "gives focus to" is simply an error and they 
meant "activates" instead. What do you think?

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

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.

Cheers
-- Tobias