Open Bug 441088 Opened 16 years ago Updated 2 years ago

nsIWebProgressListener events dispatched in inconsistent order: LIFO in nsDocLoader, and FIFO in tabbrowser

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect

Tracking

()

UNCONFIRMED

People

(Reporter: chromakode, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008060309 Firefox/3.0
Build Identifier: 

In tabbrowser.xml (http://lxr.mozilla.org/mozilla/source/browser/base/content/tabbrowser.xml#430) the tabbrowser element notifies registered nsIWebProgressListener objects in the order they registered using addProgressListener() (FIFO).

In nsDocLoader.cpp (see http://lxr.mozilla.org/mozilla/source/uriloader/base/nsDocLoader.cpp#1249), nsIWebProgressListener objects are notified in reverse order that they registered using addProgressListener() (LIFO). In the code linked, this ordering is justified for simplicity of handling removed listeners, rather than any functional requirement.

The discrepancy between these two components' dispatch orders (particularly in nsDocLoader.cpp) is confusing, and the reverse order is problematic for some listeners. For extensions utilizing a nsIWebProgressListener for browser elements, their handlers will run before the browser element has updated itself, which is undesirable in some situations, and counter the behavior of tabbrowser elements.

Reproducible: Always



Expected Results:  
Event notification in nsDocLoader.cpp should proceed in the order listeners registered in (FIFO).

Because progress event handling is useful both before and after the browser element has updated, it might be useful to add a means of specifying listener priority. This would allow listeners to be registered both before and after existing listeners.
Component: Event Handling → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.