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
12 years ago
We really need to fix this for xulrunner to be usable in a sane way for app development, I think...
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.
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.