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

[Tobias Anton]

On Donnerstag, 8. Juli 2004 01:44, bj at altern.org wrote:
> Grmbl!
> Sorry for spamming this list with this ever changing patch, but at least I
> am learning things!
>
> Now works also with <select> and <textarea>...
> Didn't add a defaultEventHandler method for HTMLTextAreaElementImpl and
> HTMLSelectElementImpl, since all is needed is to focus them... If that's
> another of my bad ideas, let me know.

Basically, that's a good idea. But it would still be better to react on the 
activate event than on the click event.

To better understand what I mean, read dom_docimpl.cpp:454:

        if (evt->id() == EventImpl::CLICK_EVENT && !evt->defaultPrevented() &&
             static_cast<MouseEventImpl*>( evt )->button() == 0) // LMB click
            dispatchUIEvent(EventImpl::DOMACTIVATE_EVENT, 
static_cast<UIEventImpl*>(evt)->detail());

So a mouse click ultimately leads to a DOMACTIVATE_EVENT, but a lot more 
happens before.

That's why I suggest that we don't generate synthetic click events (already in 
4 places in the code), but instead generate synthetic activate events. The 
disadvantage of the click events is, among others, that we must pass (0,0) 
mouse coordinates, which might confuse event handlers that expect sane values 
in the mouse coordinates field.

If you generated a DOMACTIVATE_EVENT, you might not even have to change the 
code in HTMLInputElementImpl::defaultEventHandler().

>+		form=0L;
>+		delete form;
Huh? Don't do this.

Cheers
-- Tobias