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

Status: NEW

(Core :: XUL, defect)

Description

[Asaf Romano (gone)]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

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 http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/preferences.xml#668 .  When its observe method gets called, this._pane.hasAttribute("onpaneload") should return true but returns false instead.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Boris Zbarsky [:bzbarsky]]

In particular we have code like this in the walking code:

3031     if (mPendingSheets == 0) {
3032         rv = DoneWalking();
3033     }

Comment 6

[Boris Zbarsky [:bzbarsky]]

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...

Comment 7

[Calvin Liu]

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?

Comment 8

[Calvin Liu]

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">
    <![CDATA[
    // UI-specific code
    	setTimeout(function () {/*whatever*/},100);
    ]]>
    </script>

Is it acceptable?

Comment 9

[Calvin Liu]

The onpaneload() is no use here.