[Resolved] NoScript Causes Statusbar Icons to Disappear

[therube]

NoScript Causes Statusbar Icons to Disappear in SeaMonkey Trunk?

Not certain of that, but ...

Things started with this bug, Bug 580868 - Status Bar Icons No Longer Display.

Shows as fixed, so I download an 8-2-10 build, yet still not working (Windows). Misak commented in the bug that not working for him either (Linux).

<NeilAway> therube/misak: hmm, both my Windows and Linux builds work, at least with ABP
<therube> NeilAway: build your own, the 08-02-10 download from latest-comm-central-trunk ?
<therube> mine is from latest-comm-central-trunk
<therube> s/build your own/build your own OR
<NeilAway> therube: yeah, built Linux 3 hours ago and Windows 15 hours ago
<therube> i'll see what happens with an 8-3-10 build, & if that isn't working, i'll comment in the bug
<NeilAway> therube: also, when the bug I fixed occurs, you can demonstrate it using DOM Inspector
<NeilAway> therube: open DOM Inspector, choose to inspect the browser's chrome window, expand the <window> element, scroll down to and expand the <statusbar> element
<therube> NeilAway: how to do that?
<NeilAway> file/inspect chrome document/seamonkey
<therube> heh, must have read my mind cause i hadn't yet posted the above , was instead opening browser & about to open DOM
<NeilAway> now, when you have view/show anonymous nodes disabled, you should be able to find the statusparbnel with an id of abp-status
<NeilAway> but when you have view/show anonymous nodes enabled, it disappears!
<NeilAway> the trouble is that it's easy for unsuspecting code to trigger the bug, so some other extension might also be doing it
<therube> NeilAway: ok i've got abp-status, flashgot-media-status flashgot-progresspanel, & various noscript-status*, but no icons
<therube> left me disable noscript & flashgot & see if that changes anything
<therube> aha! now i've got ABP icon showing
<KaiRo> seems like someone else does bad things there
<therube> enable FlashGot & still have ABP icon
<therube> got to youtube.com, play a video & I get the FlashGot icon
<therube> re-enable NoScript & ... icons are gone again
<KaiRo> So NoScript being the cause? Has a quite active developer, so should get a fast fix if you tell him what to do, I guess.

[therube]

<NeilAway> therube: interesting... well the bug in charsetOverlay.js was that it was accessing document.documentElement before onload
<NeilAway> therube: which itself was then accessing the statusbar before onload
<NeilAway> therube: but the bug could occur if he accessed the statusbar directly before onload

I'm in the process of going through older 2.0 rc's ...

With noscript-1.9.9.99.xpi & noscript-2.0.xpi, no status bar icons.
With noscript-1.9.9.98rc4.xpi, I get the ABP icon, though no NoScript icon (though I don't think that .98rc4 even works on the <current> Trunk?).

Correct. While 98rc4 is "installed" & Preferences can be opened, it is ineffectual. With 98rc4, ABP icon displays & FlashGot Media icon displays when playing a youtube video.

With noscript-1.9.9.99.xpi, NoScript is effective, though no ABP icon nor FlashGot media icon (& no NoScript icon).

To make clear, this is an issue on the SeaMonkey Trunk, 2.1a3.

irc://irc.mozilla.org/seamonkey

[therube]

Same results with all (including SeaMonkey inbuilt) extensions disabled, i.e. only NoScript enabled.

ftp://ftp.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk

[therube]

NoScript is not going to be the only extension that cause this disappearing icon trick .

* iav_work disable near that all addons, keep "perspective. and see icon!
* iav_work will enable by one to find a "blocker"
<iav_work> it's xsidebar
<iav_work> hello, ratty...

<therube> ok, can confirm that xsidebar-1.1.xpi causes the ABP icon to disappear
<therube> ditto for xsidebar-1.unstable.xpi (aka 1.2a2)

http://xsidebar.mozdev.org/installation.html

<therube> so do we need a better fix, or do we put the onus on extension developers ?
<therube> or a new bug ?

[therube]

news://news.mozilla.org:119/g56dnTkfUJt7rsrRnZ2dnUVZ_jWdnZ2d@mozilla.org

Extension authors, please avoid accessing elements the XUL DOM from top-level scripts. (Accesses to window and document are OK.) There is an issue which can cause the document not to display correctly in certain circumstances. These circumstances now occur more often in nightly builds of SeaMonkey 2.1a3pre.

I shall take the current developer preview of NoScript as my example. The noscriptOverlay.js file is loaded by the noscriptOverlay.xul as part of document creation. Some of the script in this file runs during the overlay process. In particular a method noscriptOverlay.install() is called directly from the last line of the script. This method makes a (safe) access to window.addEventListener, and an unsafe access to document.documentElement.

Accessing document.documentElement from top-level overlay script has recently become particularly unsafe as a result of the lightweight theme code, as the first such access now has the side-effect of initialising lightweight themes. (Normally lightweight themes would not initialise until the XUL document layout is started, just before the load event.) Although the XBL binding used for this purpose does not itself suffer from the bug, the lightweight theme initialisation also needs to access the status bar element.

Firefox happens to be unaffected by the document.documentElement version of the unsafe access because it also applies lightweight theming to its find bar. It is still vulnerable to unsafe status bar element access, although presumably no extensions do this anyway since it would already have triggered the bug.

The XBL binding for the status bar element, like many XBL bindings, contains a <children> element that tells the layout engine where the status bar panels should appear. When the element is first accessed, either from script or by the layout engine, the existing children are logically moved into that point in the binding. Additional elements added through regular DOM mutation trigger a notification to the XBL to update its list of logical elements.

However additional elements added through overlays do not trigger this notification, as the document has not loaded yet. This means that they are ignored by XBL, and simply do not appear.

This particular bug is caused by the combination of top-level overlay script, an XBL binding with a <children> element and an overlay insertion point. However there may be other hidden bugs caused by accessing DOM elements from top-level overlay scripts. The ideal solution is to defer your DOM element access to your load event handler. We recently fixed charsetOverlay.js which had the same bug (580868) this way.

[Giorgio Maone]

Fixed in latest development build, thanks.

[therube]

ICONS, ICONS.
Thank you .