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

UNCONFIRMED
Unassigned

Status

()

Core
Event Handling
UNCONFIRMED
10 years ago
10 years ago

People

(Reporter: Chromakode, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
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.
You need to log in before you can comment on or make changes to this bug.