55288 - XBL event handlers should fire last.

Status: RESOLVED WONTFIX

(Core :: XBL, defect, P3)

Description

[David Hyatt]

XBL event handlers should fire after normal DOM handlers.

Comment 1

[Peter Trudelle]

->moz0.8

Comment 2

[Peter Trudelle]

->moz0.9

Comment 3

[Peter Trudelle]

->future

Comment 4

[Blake Ross]

hyatt, I thought you were going to try for this in the .9 or 1.0 timeframes?  
This is blocking a couple other bugs, iirc.

Comment 5

[Brendan Eich [:brendan]]

Nominating.  Future doesn't mean "far future", at least the way it's being used
these days (I hope!).

/be

Comment 6

[basic]

may I ask what is the rationale behind this? And is there a way to ensure that
an event handler is fired first?

Comment 7

[basic]

read the XBL1.0 doc, understand rationale. From what I've seen isn't this bug
already fixed? But we need a way to create event handlers that fire before
normal DOM event handlers...

Comment 8

[[e-mail]]

Currently capturing event handlers aren't guaranteed to fire before bubbling
event handlers when the handlers are registered on the event target.

Perhaps you can register a capturing event handler on the document or the window?

Comment 9

[Jonathan Watt [:jwatt]]

This seems totally random to me. I am even getting bubbling event handlers
applied using XBL to the window object firing before other capture event
handlers attached to the window object. At
http://www.mozilla.org/projects/xbl/xbl.html it says:

XBL event handlers always fire last, after all other event handlers at the same
position in the event flow. Since XBL handlers usually constitute the default
actions for a widget, this allows authors in the bound document to write events
that potentially suppress the default actions taken by the XBL handlers. 

If there is really no prospect of this being fixed in the near future can
someone please change that page to point to this bug. There are a heap of other
things that that doc talks about as if they work too which don't. It could save
such a lot of time debugging and creating testcases if documentation reflected
the actual state of the implementation. 

Comment 10

[Jonathan Watt [:jwatt]]

Attachment: two events

After further investigation I have discovered some behaviour that I believe may
help in understanding the root of this bug. The attachment explains this
further and demonstrates that there is actually a difference depending on which
keys are pressed, and that there seem to be two events.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase corrected to show this bug

Comment 12

[Boris Zbarsky [:bzbarsky]]

Hmm... shouldn't XBL event handlers just all go in the system event group?  See
the code at
http://lxr.mozilla.org/seamonkey/source/content/xbl/src/nsXBLBinding.cpp#746

Or do I misunderstand what the system event group is for?

Comment 13

[Boris Zbarsky [:bzbarsky]]

Or perhaps we just need a new "xbl event group"?

Comment 14

[David Hyatt]

This bug is totally obsolete now that system groups exist.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Well.... XBL event handlers are NOT in the system group.  Or are you saying they
shouldn't be?

Comment 16

[Benjamin Smedberg]

Neil and I put together a patch that allows <handler phase="system"> in bug
225563, awaiting reviews.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Well, what's the goal here?  Do we want some XBL handlers to act like normal DOM
handlers?  Or do we want them all to act like "system" handlers?

Comment 18

[Benjamin Smedberg]

If I were redesigning the XBL spec from scratch, I would probably make "system"
the default phase and make bindings specify "bubbling" if they wanted it.
However,  I'm pretty sure changing the default event phase to "system" would
break large parts of the mozilla UI (lots of pain, little gain).

--BDS

Comment 19

[Boris Zbarsky [:bzbarsky]]

Well, the gain is a more usable XBL...

Comment 20

[David Hyatt]

Why would a handler say phase="system"?  I thought being in a group meant you are in a totally 
separate bubbling/capturing pass?

Sorry, I don't know very much about this group stuff, and until I do, it's hard for me to understand what 
XBL should be doing.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Yeah, phase and group are actually totally separate concepts -- you can have
capuring handlers in the system event group.

So imo we should make the default event group the system one, make it possible
to put handlers in the non-system group, and fix anything that breaks...

Comment 22

[David Hyatt]

Talking out my ass for a second, it seems like

(a) XBL should support having its handlers put anywhere that the DOM can put them, e..g., in any group 
and in any phase, etc.  This should be part of the XBL language.

but

(b) chrome XBL (vs. content XBL) should possibly have a notion of what to do by default with the 
handlers, so, e.g., perhaps chrome XBL considers all the handlers to be default actions that could be 
stopped by preventDefault, belong to some specific group, etc.  This could involve both the type 
(chrome/content) of the bound document as well as the type (chrome/content) of the XBL document.

Comment 23

[Benjamin Smedberg]

The hard part is, that the DOM specs have no notion of a system event group (at
least as far as I have found)... it's a mozilla-specific pass that we use to
provide a default action for various elements. For the purposes of the XBL spec,
then, are we going to define something new that is not in the DOM events spec?

I don't think we should try to make a distinction between chrome and content XBL
for this. There isn't a good way to tell what a chrome author might intend, and
we don't want the same XBL file to behave differently if it's loaded as content
as opposed to chrome.

Can't we just add a new attribute <handler group="system|content"> which
defaults to system, and let's see what breaks? (Keeping the phase="" attribute
as it is now, defaulting to bubbling). Since the purpose of XBL is to provide
"default" actions, this seems like the correct behavior.

Comment 24

[Brian Ryner (not reading)]

> The hard part is, that the DOM specs have no notion of a system event group (at
> least as far as I have found)... it's a mozilla-specific pass that we use to
> provide a default action for various elements. For the purposes of the XBL spec,
> then, are we going to define something new that is not in the DOM events spec?

No, but DOM 3 provides for event groups which can fire in an
implementation-defined order.  So while this would be something not in the DOM
events spec, it certainly doesn't contradict the spec.

Comment 25

[[e-mail]]

OK, so do we want group="system" on all bindings, or will that break anything?

Comment 26

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 27

[Boris Zbarsky [:bzbarsky]]

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.