[Bug 12949] click() shouldn't have special powers over dispatching click event manually

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12949

--- Comment #35 from Jonas Sicking <jonas@sicking.cc> 2011-09-04 07:33:02 UTC ---
Apparently we didn't get enough bugs filed that we decided to change our
implementation. We only changed our implementation in order to make sure that
callers of HTMLAnchorElement.click() got the behavior they expected.

I agree with Anne here. Events are a notification mechanism indicating that
"something" just happened. They also carry the ability to stop whoever
dispatched the event from taking the action they normally would in response to
the "something" that just happened.

There are two problems with letting target.dispatchEvent() cause the default
action to take place.

1.
We can't do that for a lot of events with default action since it doesn't
really make sense. For example the default action for the "error" event in
indexedDB is to cancel the transaction, but there might not be a transaction
running if dispatchEvent is used.

And for the app-cache, the default action is to show various UI, but just
calling dispatchEvent doesn't provide enough information as to what UI would be
displayed. Additionally we probably don't want the page to be able to bring up
app-cache UI at will.

And the default action for the "dragstart" event is to initialize a drag'n'drop
operation. How would that work if the user isn't currently performing a
drag'n'drop action with the mouse (or touch-screen once we have drag'n'drop
there).

2.
If .dispatchEvent causes the default action to run, then that creates a weird
secondary meta-API which provides largely duplicated functionality. For example
if we let the "error" event in indexedDB abort the current transaction if there
is one, then that would be duplicated API since transaction.abort() is already
available.

And if we make dispatchEvent of a "keydown" event with .char set to " " execute
the default action of dispatching a "click" event, then that means that we have
two APIs for dispatching "click" events.


In short, events are fired in response to various things happening. They are
not a meta-API for causing things to happen.


I'm aware that we've put some of the default action logic in the event-dispatch
code in Gecko, but I think that's the wrong design. Feel free to grab me on irc
or elsewhere to discuss what a better design should be.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 4 September 2011 07:33:10 UTC