Re: Firing events at the window vs. firing them at the chrome event handler
On 03/04/2013 08:20 PM, Boris Zbarsky wrote: On 3/4/13 1:08 PM, Zack Weinberg wrote: It only needs to be certain of seeing the event despite anything content can do, In that case, a capturing handler on the chrome event listener will work fine. -Boris or capturing or bubbling event listener in system event group. http://mxr.mozilla.org/mozilla-central/source/content/events/public/nsIEventListenerService.idl#72 Listeners in system event group are called after the default group, but stop*Propagation is per group. Listeners added by content js are only in the default group. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 3/4/13 1:08 PM, Zack Weinberg wrote: It only needs to be certain of seeing the event despite anything content can do, In that case, a capturing handler on the chrome event listener will work fine. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 2013-03-04 9:53 AM, Boris Zbarsky wrote: On 3/4/13 9:10 AM, Zack Weinberg wrote: So I guess the next question is where does one put a capturing event handler so that it will see *all* events of the relevant type regardless of which window it was dispatched to or the contents of that window I don't think such a thing is possible in a world in which stopImmediatePropagation exists, is it? As in, if you have two handlers which both try to (1) see all events and (2) make sure nothing else sees them, then one of them will lose. It only needs to be certain of seeing the event despite anything content can do, and despite arbitrarily weird XUL structure. Also, I don't need to prevent anyone else from seeing the event, I just need to make sure that this handler does see it. (This is in aid of bug 650960, where I'm trying to replace direct C++ invocation of a dialog box with an indirection through an event, making it easier to replace the dialog box with a better UX later. For that, it might be more convenient in the long term if bubble-phase semantics applied within the chrome, so that a tab-level handler _could_ swallow an event and present tab-scoped UX, but if there was no tab, the global backstop would still apply. But that might be more complicated than I care to get into right now.) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 3/4/13 9:10 AM, Zack Weinberg wrote: So I guess the next question is where does one put a capturing event handler so that it will see *all* events of the relevant type regardless of which window it was dispatched to or the contents of that window I don't think such a thing is possible in a world in which stopImmediatePropagation exists, is it? As in, if you have two handlers which both try to (1) see all events and (2) make sure nothing else sees them, then one of them will lose. If you ignore that part, putting a capturing handler on the toplevel chrome window would presumably work, I think. the immediate followup is whether it's possible for that handler to retrieve the window (originalTarget?) and learn its chrome structure (e.g. 'is this document in a tab, and if so, which tab?') The event.target and event.originalTarget should presumably work correctly, yes. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 2013-03-03 10:25 PM, Boris Zbarsky wrote: On 3/3/13 10:12 PM, Zack Weinberg wrote: If an event is dispatched from C++ using nsContentUtils::DispatchTrustedEvent with both the 'bubbles' and 'cancelable' flags set false, what precisely is the difference between targeting it at a document's window and targeting it at the document's window's chrome event handler? The main difference is whether the web page will be able to see the events, I think. That's also what I thought, but it's good to have confirmation. In particular, if such an event is targeted at the window, is there any circumstance in which a handler registered from chrome JS on gBrowser will *not* get a crack at it? If it's a capturing handler, it should work, assuming nothing else higher up in chrome captures and eats them... So I guess the next question is where does one put a capturing event handler so that it will see *all* events of the relevant type regardless of which window it was dispatched to or the contents of that window, and the immediate followup is whether it's possible for that handler to retrieve the window (originalTarget?) and learn its chrome structure (e.g. 'is this document in a tab, and if so, which tab?') zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 3/3/13 10:12 PM, Zack Weinberg wrote: If an event is dispatched from C++ using nsContentUtils::DispatchTrustedEvent with both the 'bubbles' and 'cancelable' flags set false, what precisely is the difference between targeting it at a document's window and targeting it at the document's window's chrome event handler? The main difference is whether the web page will be able to see the events, I think. In particular, if such an event is targeted at the window, is there any circumstance in which a handler registered from chrome JS on gBrowser will *not* get a crack at it? If it's a capturing handler, it should work, assuming nothing else higher up in chrome captures and eats them... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Firing events at the window vs. firing them at the chrome event handler
If an event is dispatched from C++ using nsContentUtils::DispatchTrustedEvent with both the 'bubbles' and 'cancelable' flags set false, what precisely is the difference between targeting it at a document's window and targeting it at the document's window's chrome event handler? In particular, if such an event is targeted at the window, is there any circumstance in which a handler registered from chrome JS on gBrowser will *not* get a crack at it? zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
