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

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.

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.

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.