1196477 - [e10s] Startup crash with NoScript

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'm looking at this set of crashes on Aurora:
https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=3&range_unit=days&date=2015-08-18&signature=mozalloc_abort%28char+const*+const%29+|+NS_DebugBreak+|+Initialize%28%29&version=Firefox%3A42.0a2#tab-reports

Right now it's #10 overall on Aurora.

Example:
https://crash-stats.mozilla.com/report/index/ea31ba3b-2ea8-4567-8d9f-778592150816

Crash-stats reports no add-on correlation, but I've looked at about 10 reports and they all have NoScript.

Benjamin, do you know what might be happening here? It's a bit hard to tell if we're doing something wrong or of NoScript is. Somehow AddSitesToFileURIWhitelist seems to be triggering recursive initialization of some service.

Comment 1

[Giorgio Maone [:ma1]]

This is easily reproducible by checking "NoScript Options>Advanced>Trusted>Allow local links" and restarting the browser.

That preference is there for historical reasons, since NoScript does not use CAPS anymore.
When NoScript still relied on CAPS, it was necessary because multiple policies caused unpredictable interactions: therefore if users actually needed to link local files they unfortunately had to do it for all their whitelisted sites at once, even though this was mitigated by further hooks in nsIContentPolicy providing better granularity.

Now that bug 1036656 has been fixed, I believe I can remove this "feature" completely and suggest the (hopefully few) users relying on it to revert to old-style prefs.js CAPS hacking.

Comment 3

[Giorgio Maone [:ma1]]

This should be fixed by https://addons.mozilla.org/firefox/downloads/file/340324/noscript_security_suite-2.6.9.36rc2-sm+fx+fn.xpi?src=devhub

Rather than removing the "feature", I deferred the CAPS initialization of checkloaduri permissions, which used to happen in "profile-after-change", until the the content process creates its first window global instead.

The crash is not reproducible anymore with NoScript 2.6.9.36rc2 in the way I outlined in comment 1, which still work in 2.6.9.36rc1.

I plan to release in the stable channel later today.

Feel free to reopen if the crash keeps being reported in correlation with NoScript.