Last Comment Bug 286013 - DOM dispatches undocumented events and expects embedders to handle them
: DOM dispatches undocumented events and expects embedders to handle them
Status: ASSIGNED
:
Product: Core
Classification: Components
Component: Embedding: APIs (show other bugs)
: Trunk
: x86 Linux
: -- normal with 2 votes (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
:
Mentors:
Depends on: 238044
Blocks: 257162
  Show dependency treegraph
 
Reported: 2005-03-13 17:49 PST by Boris Zbarsky [:bz]
Modified: 2011-08-15 13:38 PDT (History)
22 users (show)
pavlov: blocking1.9-
reed: wanted1.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Boris Zbarsky [:bz] 2005-03-13 17:49:48 PST
We have events that are dispatched by DOM code and expected to somehow affect
the UI of the app.  This makes them effectively part of our embedding API (since
it's impossible to write a browser that has current Seamonkey/firefox
functionality without dealing with these events).

If this is the api we want, we should document and freeze it appropriately.  If
we want to expose this functionality in a more embedding-friendly way, then we
should do so.

We have at least the following event names used by either the UI or extensions
(e.g. xforms):

DOMLinkAdded
DOMLinkRemoved
DOMWillOpenModalDialog
DOMModalDialogClosed
DOMWindowClose
fullscreen
PopupWindow
DOMContentLoaded
DOMTitleChanged
PluginNotFound

At least the following used by "core" code like accessibility:

ValueChange
DOMMenuItemActive

And the following that we fire but seem to be unused?

DOMFrameContentLoaded
windowZLevel
Comment 1 Boris Zbarsky [:bz] 2005-11-17 10:25:58 PST
We really need to fix this for xulrunner to be usable in a sane way for app development, I think...
Comment 2 Boris Zbarsky [:bz] 2006-08-17 16:06:58 PDT
So we should really try to at least document that these events can get fired and when, and what parts of a browser can't be implemented without listening for them.
Comment 3 Eric Shepherd [:sheppy] 2006-09-15 12:46:03 PDT
I've been planning to do a significant documentation effort to track down events and get them all documented in logical places; there are events everywhere that aren't well documented, or are documented but absurdly hard to find, so this will fit in nicely with that plan.

That's the long way of saying I'll take this, but will likely be pinging folks for info when I do start work on it.
Comment 4 Ray Kiddy 2007-07-19 21:21:12 PDT
I am not sure of the best way to go on this, but I wanted to make a start at something. I thought I would try to identify the methods that are used to send events. This led me to:

nsContentUtils::DispatchTrustedEvent

This led me to:

nsHTMLLinkElement::CreateAndDispatchEvent
nsHTMLSelectElement::DispatchDOMEvent
nsGlobalWindow::DispatchCustomEvent
nsGlobalWindow::FireOfflineStatusEvent

The first two are only used in one or two files, but The DispatchCustomEvent is used all over the place. Basically, it led me into the weeds.

Is there a marker of some kind for event names? It is helpful that these names are just strings. One can avoid lots of dependencies and bad design with that, but it is helpful if event names were to follow some standard form, or be marked in some recognizable way.

It is a shame one cannot set up an event listener that just listens for every event. Or, at least, I cannot see how to do it. It is sometimes convenient to be able to, on a Mac, set up a notification listener using a null for the notification name. It just listens for everything.

Note You need to log in before you can comment on or make changes to this bug.