proposed changes for command event handling

[Brian Ryner]

I've been thinking some about the way that we retarget events based on the
command= attribute in XUL. Its current behavior seems to be kind of broken:
the event keeps its target and originalTarget if it had been retargeted (by
crossing an anonymous content boundary), otherwise, both target and
originalTarget are reset to the <command> element the event is redispatched
to.

I'd propose that we change this to be more consistent, by:

- creating a new nsEvent, rather than reusing the old one
- copying the modifiers from the old event
- adding a new property for command events called sourceEvent. This will
refer back to the original DOM event.
- Dispatching the new event to the <command> element and allowing it to
capture and bubble as normal

I think this helps in a number of ways -- it makes the dispatch consistent
with what the DOM events spec says (the event target is the origin of
capturing and bubbling). It makes things consistent between command events
that originate from inside of an XBL binding and those that don't. And, it
allows the event handlers full access to the original event, should they
need it.

There's a small chance that a change like this could break code that
(knowingly or not) depends on the current behavior. My gut feeling is that
this is pretty unlikely. What do you guys think?

--
-Brian

[Brian Ryner]

Here's another inconsistency along the same lines: Given the following XUL:

<command id="cmd_foo" oncommand="doSomething();"/>
<button id="btn" command="cmd_foo"/>

At document construction time, the broadcaster mechanism inherits the
oncommand= from cmd_foo onto btn. When the button is clicked,
nsXULElement::PreHandleEvent prevents the default behavior of firing the
handler via the oncommand attribute. It instead redispatches the event to
cmd_foo. This accomplishes two things:

- It causes the handler to only get compiled once, no matter how many
elements refer to the command
- It causes |this| to refer to the command element from inside the handler

These are both good arguments for the behavior, I think, and if that's the
case, why are we only doing this if the event's originalTarget is the
element with command=? That is, if I put a button inside of an XBL binding,
and put the command= on the bound element, I don't get this retargeting
behavior because the originalTarget doesn't match. Instead, it executes the
oncommand handler inherited from the <command> via the broadcaster system.

It seems like this should be consistent no matter where the element with
command= is. Any thoughts?

--
-Brian

[Jonas Sicking]

Brian Ryner wrote:

> I've been thinking some about the way that we retarget events based on the
> command= attribute in XUL. Its current behavior seems to be kind of
> broken:
> the event keeps its target and originalTarget if it had been retargeted (by
> crossing an anonymous content boundary), otherwise, both target and
> originalTarget are reset to the <command> element the event is redispatched
> to.
>
> I'd propose that we change this to be more consistent, by:
>
> - creating a new nsEvent, rather than reusing the old one
> - copying the modifiers from the old event
> - adding a new property for command events called sourceEvent. This will
> refer back to the original DOM event.
> - Dispatching the new event to the <command> element and allowing it to
> capture and bubble as normal

This sounds great! What type should the new event be of though? I guess
we currently fire the same type as was dispatched at the element with
the command="..." attribute and chaning that would be hard?

Though ideally it feels like we should dispatch an event with type
"commandActivate" or similar?

/ Jonas

[Jonas Sicking]

Brian Ryner wrote:

> Here's another inconsistency along the same lines: Given the following
> XUL:
>
> <command id="cmd_foo" oncommand="doSomething();"/>
> <button id="btn" command="cmd_foo"/>
>
> At document construction time, the broadcaster mechanism inherits the
> oncommand= from cmd_foo onto btn. When the button is clicked,
> nsXULElement::PreHandleEvent prevents the default behavior of firing the
> handler via the oncommand attribute. It instead redispatches the event to
> cmd_foo. This accomplishes two things:
>
> - It causes the handler to only get compiled once, no matter how many
> elements refer to the command
> - It causes |this| to refer to the command element from inside the handler

Wouldn't the same thing be accomplished if we didn't copy the oncommand=
attribute to the <button> but rather dispatched a "command" event to
whatever element the command-attribute points at? That seems like a
better solution to me.

> These are both good arguments for the behavior, I think, and if that's the
> case, why are we only doing this if the event's originalTarget is the
> element with command=? That is, if I put a button inside of an XBL
> binding,
> and put the command= on the bound element, I don't get this retargeting
> behavior because the originalTarget doesn't match. Instead, it executes
> the
> oncommand handler inherited from the <command> via the broadcaster system.
>
> It seems like this should be consistent no matter where the element with
> command= is. Any thoughts?

Yes, absolutely! The current behaviour sounds more like a bug than
anything else. At least from a users point of view.

This is especially vital since with xbl2 .originalTarget is going away.

/ Jonas