Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 286013 - DOM dispatches undocumented events and expects embedders to handle them
: DOM dispatches undocumented events and expects embedders to handle them
Product: Core
Classification: Components
Component: Embedding: APIs (show other bugs)
: Trunk
: x86 Linux
: -- normal with 2 votes (vote)
: ---
Assigned To: Johnny Stenback (:jst,
: Myk Melez [:myk] [@mykmelez]
Depends on: 238044
Blocks: 257162
  Show dependency treegraph
Reported: 2005-03-13 17:49 PST by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2016-08-19 12:14 PDT (History)
21 users (show)
pavlov: blocking1.9-
reed: wanted1.9+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Boris Zbarsky [:bz] (still a bit busy) 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):


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


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

Comment 1 Boris Zbarsky [:bz] (still a bit busy) 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] (still a bit busy) 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:


This led me to:


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.
Comment 5 Benjamin Smedberg [:bsmedberg] 2016-06-23 10:47:41 PDT
Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.

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