286013 - DOM dispatches undocumented events and expects embedders to handle them

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: APIs, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

We really need to fix this for xulrunner to be usable in a sane way for app development, I think...

Comment 2

[Boris Zbarsky [:bzbarsky]]

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]]

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]

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.

Comment 5

[Benjamin Smedberg]

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.