activate vs. click event

[Tobias Anton]

On Freitag, 9. Juli 2004 15:38, bj at altern.org wrote:
> Problem: currently, radio buttons and checkbox react on the MOUSEUP_EVENT.

Yeah, but this is wrong and should therefore be changed. (Patch attached)

> 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 see what you mean.

But the onclick event listener should indeed _not_ be executed after the 
default event handler for the CLICK_EVENT. Reason: the event listener might 
cancel the event, which in turn should prevent the default action.

And how can an event listener prevent something that already has happened?

But I assume that there are web sites that expect a browser to cope with that 
code, so a solution must be found. If we don't, we must leave another bug in 
the code, namely that an onclick event listener cannot cancel clicks on form 
elements.

I have an idea but I ain't really glad about it. Click events could 
preventDefault() unless they return true. (Hack attached)

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

1) Would be fine for me. Since we don't visualize accesskeys (which we should 
do according to the spec), it might be better to see which element would 
react to an accesskey before it is activated.


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

Yes, and "activate" corresponds perfectly to the activate event.
What I hate about the current situation is that we have a bug in our 
implementation and instead of fixing it, we implement a new feature based on 
that bug.

Additionally, we're promoting code duplication. The code of the click()-method 
exists in three places already. With your patch, it would be four in total.
The line 
	setChecked(m_type == RADIO ? true : !checked());
exists in two places, and you're about to add another.


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

Is it really necessary to support a broken html construct as you mentioned 
above? When looking at the w3c spec, it must fail when used on checkboxes.


> > 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.
I agree. I'm a keyboard user, too.

But what we're doing here is violating the specification and fails on sites 
with special mouse handling even though it's a keyboard event.

That said, I vote for your patch, since it is well reviewed and there are 
enough other places that violate the separation of keyboard and mouse events 
already.
E.g. all other elements supporting the accesskey attribute are activated via 
click(), too, and I don't think it's your responsibility to fix other's code 
before contributing your own.

/me thinking about a solution for the onclick-cancellation-bug.

Cheers
-- Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: onclick-cancels-by-default.diff
Type: text/x-diff
Size: 695 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040709/218860f2/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: form-elements-react-on-activate-not-mouseup.diff
Type: text/x-diff
Size: 5269 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040709/218860f2/attachment-0001.diff>