- From: Xavier Ho <contact@xavierho.com>
- Date: Fri, 25 May 2012 13:45:55 +1000
- To: Kyle Huey <me@kylehuey.com>
- Cc: whatwg@whatwg.org, Glenn Maynard <glenn@zewt.org>, Jason Edward 今井 Parrott <parrott.jason@gmail.com>
Hello Kyle, On 25 May 2012 13:38, Kyle Huey <me@kylehuey.com> wrote: > Yes, you would need to check the entire event dispatch chain for > listeners. At that point it may be easier just to fire the event and let > the browser figure it out. It's also possible that event dispatch of an > event that never "heard" by script in the page can trigger dispatch of an > event that is "heard" by script. For example, a click event that bubbles > to a <label> element generates a synthetic click event on whatever the > <label> points to. It is possible for a page to have no event listeners > that see the first click, but have event listeners that see the second. I > think you really need to let the browser run event dispatch for all events > here. > > I was going to begin this reply by saying "Yes, we also covered label and the 'for' property", but that doesn't seem to contribute to the conversation, heh. Still valid points, though. We've done a lot of work looking at all the possible ways of events firing and covered most of them. If this project was for a particular website, we would have done what many people do -- inject our own version of addEventListener and watch it go -- but it is not the case. All of our pages are sandboxes in an <iframe> and loaded that way, and we sometimes do not have control over what can be in the page -- i.e. sites we own but not directly developed by our team. Something like a hasEventListener(DOMElement elem) will help us a lot with what we've done, and we can check for delegates by looking at parent nodes, siblings, as well as synthetic events. They are well-documented. Cheers, Xav
Received on Friday, 25 May 2012 03:47:05 UTC