Open Bug 392515 Opened 13 years ago Updated 7 years ago

xul-overlay-merged observer is notified before script elements within the overlay are processed


(Core :: XUL, defect)

Not set




(Reporter: mano, Unassigned)



The xul-overlay-merged observer is notified before script elements within the overlay are processed. see also this._self._self hack in browser-places.js
Hmm...  Can you maybe add a small testcase?  Looking at the code, I would not expect this to happen: scripts are processed as we walk, and we don't call DoneWalking till they're all done, in theory.
Duplicate of this bug: 393953
I don't have a small testcase, but here's a large, complicated one:

Note: in bug 393953, now marked as a duplicate, my experience is that the observer is notified before the overlay XUL is overlaid onto the base XUL file.

Specifically, when applications.xul (the new Applications prefpane in bug 377784) is overlaid onto preferences.xul (the Preferences dialog) in patch v9 (attachment 278386 [details] [diff] [review]), then xul-overlay-merged fires before the "onpaneload" attribute on the <prefpane id="paneApplications"> element in applications.xul gets added to the <prefpane> element with the same ID in preferences.xul.

The problem does not occur if I remove either the <script> element or the <?xml-stylesheet?> processing instruction from applications.xul.  Nor does it occur the second and subsequent times I open the Preferences dialog.

But it *does* occur even if both the <script> element and the <?xml-stylesheet?> instruction refer to empty files (i.e. it's not the content of the files that matters, merely the presence of those references in the overlay).

When it occurs, the result is that the prefpane's onpaneload code doesn't run the first time you open the Preferences dialog, so the prefpane doesn't get initialized.  In patch v10 (attachment 278530 [details] [diff] [review]) and later patches I have worked around the problem by putting the processing instruction into preferences.xul.

The observer that gets notified early is at .  When its observe method gets called, this._pane.hasAttribute("onpaneload") should return true but returns false instead.
That's really odd.  We shouldn't be calling DoneWalking() while there are pending sheet or script loads...

Can you get a C++ stack to the relevant DoneWalking call?
In particular we have code like this in the walking code:

3031     if (mPendingSheets == 0) {
3032         rv = DoneWalking();
3033     }
OK, it looks like the real issue is that we load the sheet, then move on, but the script is still loading, and because dynamic overlays don't set mStillWalking, we don't realize that.

Someone who understands the overlay stuff (esp. the dynamic overlay stuff) should make sure that we actually track pending overlay/script loads and don't move along until they finish...
I have this problem in ff3b1.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

Is there any other work around in user land? For example, can we use an event other than 'onpaneload' to do the similar job?
Well, I guess this could be a work around.

In the <overlay id=...>, we should have <prefpane id=... onpaneload="myInit();">.
So after something like '<script type="application/x-javascript" src="chrome://..." />, we use

    <script type="application/x-javascript">
    // UI-specific code
    	setTimeout(function () {/*whatever*/},100);

Is it acceptable?
The onpaneload() is no use here.
Blocks: tomtom
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
Duplicate of this bug: 473189
You need to log in before you can comment on or make changes to this bug.