[Webkit-unassigned] [Bug 17429] Inspector should show event listeners/handlers registered on each node

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=17429





--- Comment #14 from Joseph Pecoraro <joepeck at webkit.org>  2009-08-26 08:07:05 PDT ---
(In reply to comment #11)
> IIRC, there is no guarantee on the order of events firing on one element. So it
> would maybe confuse authors if you expose such a UI.

Well, we can follow Node.h's dispatchGenericEvent() to actually produce the
exact ordering of all of the event listeners for an event on a given node.  So,
whether or not the spec has guaranteed an order we can at least provide
developers with the exact ordering that WebKit will produce.

But is the spec really undefined in this regard?  I would be worried about
browser compatibility if that were the case.  Here is the most current editors
draft on DOM Event Flow:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-Events-flow

I glossed over it and I saw:
"Next, the implementation must determine the current target's candidate event
listeners. This shall be the list of all event listeners that have been
registered on the current target in their order of registration. Once
determined, the candidate event listeners cannot be changed; adding or removing
listeners does not affect the current target's candidate event listeners.

Finally, the implementation must process all candidate event listeners in order
and trigger each listener if all the following conditions are met..."

Although its still in a draft, I think this is exactly how WebKit handles event
flow and so I think we will be up to date if we can show it this way.

> On the other hand, listing events with capture first, then the target and
> finally bubbling would be nice.

Yes, I had originally intended that, and I have prepared tests for that in my
attached test case. =)

(In reply to comment #13)
> (In reply to comment #12)
> > Oh I forgot, we should find a way to list events registered on the window or
> > document.
> 
> If we are going to be adding more information like this to the elements pane,
> we may want to give some indications of document and window associated with
> that document.  I was thinking perhaps having the root node have some sort of
> pseudo-parent or sibling that was the document/window.  Not sure what it would
> look like.

Document, window, and any other EventTargets that are not temporary
(XMLHttpRequest is temporary).  A quick scan for things that extend EventTarget
(see the list below) shows ApplicationCache and Workers would be good
candidates as well.

I have had this in the back of my mind, and intentionally named this bug "on
each node" for starters.  But I really like your idea on presenting document
and window!

dom/MessagePort.h
dom/Node.h
loader/appcache/DOMApplicationCache.h
notifications/Notification.h
page/DOMWindow.h
page/EventSource.h
websockets/WebSocket.h
workers/AbstractWorker.h
workers/WorkerContext.h
xml/XMLHttpRequest.h
xml/XMLHttpRequestUpload.h

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.