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)
Core
DOM: UI Events & Focus Handling
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.
Assignee | ||
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•