(I can reproduce, using Linux Nightly.)
NoScript is a very popular add-on among Nightly users. We should consider fixing it for M2.
My survival strategy would be merging the restartless, mobile-compatible and e10s-aware but *very bitrotten* and buggy NSA++ ( http://noscript.net/nsa/#android-native ) with the "traditional", feature-completed, constantly maintained, but API-wise ancient (the original code core dates back to 2005) and almost impossible to "modernize" NoScript 2.x. It's a very expensive effort and I've already submitted some grant proposals to be evaluated in September, hoping for the best.
I've been interested in e10s for years and love to see it land in Firefox. That's why I really like to help testing it and submit telemetry data about it's usage. But my interest is mainly from a security point of view and not having NoScript available for the last couple of days has made me switch it off again. This is very unfortunate. When I read http://noscript.net/nsa/#android-native I'm a bit afraid that NoScript won't be easily ported to e10s. Is this assumption correct or is there any idea about the amount of work to make NoScript work with e10s?
What's the status here, Giorgio? Is there anything tech-savvy users of e10s-Nightly can do to help you?
(In reply to Frederik Braun [:freddyb] from comment #5) > What's the status here, Giorgio? > Is there anything tech-savvy users of e10s-Nightly can do to help you? At this moment nothing. I'm working on merging the restartless, mobile-compatible, and e10s aware (but incomplete) 3.x with the stable, feature complete but future-unfriendly 2.x. Unfortunately, at this stage the results are too messy to take advantage of any external testing / help. I'll keep you posted here, though.
Giorgio, are you having trouble with any particular bit of porting to e10s? Is there a specific object or function that you really need? We're in #e10s and about to help.
(In reply to :ally Allison Naaktgeboren from comment #7) > Giorgio, are you having trouble with any particular bit of porting to e10s? > Is there a specific object or function that you really need? We're in #e10s > and about to help. There's no specific technical roadblock so far. The slow pace is due to the fact that there are currently two divergent NoScript codebases, one (3.5.x) more modern and already e10s-compatible but mobile-oriented and feature-incomplete, and the other, the generally available 2.x, which is very rusty (with some code dating back to 2005) and quite complex. Therefore the sane thing to do would be completing the former and getting rid of the latter, rather than investing on hacking the legacy code, but at the same time I need to keep the stable product up-to-date until the new code is production-ready. However, should I stumble on any API or platform support problem I'll surely use your help, thank you!
please do use NEEDINFO and let me know. Good luck.
Adding "dogfood" keyword so this bug shows up on the e10s wiki's list of known issues: https://wiki.mozilla.org/Electrolysis#Known_Issues
Firefox 35 is now on Aurora channel with e10s by default; I assume Bug 1085096 is a duplicate of this.
e10s is not enabled by default on Nightly or Aurora. In fact, e10s prevents itself from being enabled on Aurora, Beta, and Release channels. :)
k, a change to support e10s broke this for non-e10s using clients ;) My daily browser Aurora and my testing browser Nightly are unusable messes.
e10s is since e few days enabled by default in Nightly and by happy coincidence NoScript works for me with e10s now. Very nice!
Giorgio, is NoScript expected to work with e10s on the Nightly channel now?
No, not fully at least. For instance, placeholders for blocked embeddings cannot work. I'm working on it, but it's too early even for beta testing.
It is working fine for me. I switched to Nightly today, since Aurora has been culled (I think it is a shame). But the NoScript development version runs fine apparently. I didn't try anything strange with it yet though.
(In reply to gijsbertth from comment #18) > It is working fine for me. I switched to Nightly today, since Aurora has > been culled (I think it is a shame). JFY: https://developer.mozilla.org/en-US/Firefox/Developer_Edition/Reverting#Reverting_to_Firefox_Aurora
I still see broken first loads while NoScript is enabled on pretty much pristine profile. During the first load images will be broken and websites will only load half resources in addition to not receiving cookies (which means that during the first load I will appear to be logged out from everywhere). Refreshing the page/forcing image reload will then load it just fine. It might be caused by my NoScript config though.
(In reply to Simonas Kazlauskas [:simukis] from comment #20) > I still see broken first loads while NoScript is enabled on pretty much > pristine profile. During the first load images will be broken and websites > will only load half resources in addition to not receiving cookies (which > means that during the first load I will appear to be logged out from > everywhere). Refreshing the page/forcing image reload will then load it just > fine. It might be caused by my NoScript config though. I see the same, plus some nasty hangs that forced me to disable it. Even disabling script blocking wasn't sufficient. Better wait for the new version :)
I've noticed that some people are reporting that NoScript is working for them under e10s, however I'm seeing the behaviour described in comment 0 still. If there an update on a NoScript 3.5 beta at all?
NoScript 188.8.131.52 (current stable) is "kind of" working on E10, mostly thanks to the add-ons compatibility layer I noticed Mozilla kindly included in latest Nightly builds. Currently available NSA++ (3.5 alpha), instead, stopped working on Firefox 34 for Android, and I'm hoping to fix it ASAP (maybe even today). Bottom line: things are pretty fluid at this moment, so I'd be very grateful to people who could check and report as much as they can.
Hi Giorgio, Thanks for the update, I was waiting for this! NoScript does indeed "kind of" work with E10S enabled. I've checked on Facebook and Reddit, and can confirm scripts block and are allowed succesfully with NoScript 184.108.40.206 RC3 and E10S enabled Not seeing any major errors in the console either. Only Reference Errors with Yahoo not being defined (but I presume thats wider Firefox and not due to NS)
Giorgio, Initial telemetry data is in, and Noscript throws a js exception regularly. The exception, as far as gecko can tell, is not associated with a filename. So that probably means that it's throwing when trying to load something. We're also seeing an exception thrown in RemoteAddonsParent.jsm line 7, http://mxr.mozilla.org/mozilla-central/source/toolkit/components/addoncompat/RemoteAddonsParent.jsm#7. This one is worrying to me, as your addon is causing bustage inside chrome code. Thought you'd like to know
Thanks for the heads up. I am currently traveling right now and cannot look into this before the end of next week. I will let you know ASAP.
(In reply to Darren Olivier from comment #24) > NoScript does indeed "kind of" work with E10S enabled. I've checked on > Facebook and Reddit, and can confirm scripts block and are allowed > succesfully with NoScript 220.127.116.11 RC3 and E10S enabled I'm seeing it… sort of work, but not always block scripts when it should. I haven't tried to characterize exactly when this occurs, yet — it's not “officially” expected to work at all in e10s mode, if I understand correctly.
(In reply to please NEEDINFO? :ally Allison Naaktgeboren from comment #26) Ally, I looked into this, and I couldn't find any trace of exceptions thrown by NoScript, either on startup (when it lazy loads a lot of stuff) or during browsing. I looked at the terminal dumps and at the browser console: is there any other place I should watch? Also, do these exceptions have any type/name/additional info for identification? Regarding http://mxr.mozilla.org/mozilla-central/source/toolkit/components/addoncompat/RemoteAddonsParent.jsm#7 -- unless the source code changed in the meanwhile, an exception thrown from there ("const Ci = Components.interfaces;") sounds very unlikely to happen to me, and even less likely to be NoScript-related. I'm really puzzled: what's the raw data you based your conjecture on, and where should I begin to investigate? Thank you!
(Leaving Ally's needinfo open, in case she digged deeper or wants to highlight something else) I see a lot of messages related to NoScript in the browser console, so I'll help you reproduce: STR: - Install nightly in a new profile - Make sure e10s is enabled (Settings) - Install Noscript and restart browser. - Observe warnings in the browser console (Tools - Web Developer - Browser Control (CTRL+Shift+J) -- Copy of warnings at http://dpaste-bkero.paas.allizom.org/rgrO/raw - Let's look into additional errors - Cleared the browser console (clear button) - Navigate to example.com - two more exceptions (and a lot more 'unsafe CPOW usage' warnings) -- Copied here http://dpaste-bkero.paas.allizom.org/xCY4/raw Oh and one more thing: I did not find any errors or exceptions related to line 7 of RemoteAddonsParent.jsm, but looking at the file (and its history), the most likely error to ever come out of this line is a "redeclaration of const" :)
Giorgio, as frustrating as it is, I don't have the error message due to privacy restrictions. In this case the js engine could not find a file associated with the error to report it in (the js engine sending errors to gecko is somewhat complicated)
The raw data from the last sample is here, you'll need your addonId to locate your entries: http://nbviewer.ipython.org/gist/vitillo/571e075a2061462dca93 On the joined list your entries are: noscript FILE_NOT_FOUND 0 3.80% noscript RemoteAddonsParent.jsm 7 1.80% https://bugzilla.mozilla.org/show_bug.cgi?id=1111730#c8
Thank you both. Looks like I've got enough stuff to be fixed / moved around to keep me busy for weeks :(
(In reply to Giorgio Maone from comment #33) > Thank you both. > Looks like I've got enough stuff to be fixed / moved around to keep me busy > for weeks :( I know it's tough. Hang in there!
3 years ago
Not sure if that helps, but I'm madly using tiletabbing with noscript and e10s ON (since today due to IME issue I didn't even notice). I can write that I noticed these two things so far: - alert box sometimes appears "Do You want to navigate away", - a site reports with alert box that it could not load some js require file. I can guess the thing reported in comment #28 , that not all scripts are being blocked, is taking place. Maybe it has something to do with multiple sites loading at the same time "flooding" noscript code making it miss certain script file (like it's blocked late or not blocked at all due to function not finishing or being busy)?
Images not loading fix: Enable back Noscript if You previously disabled it and, Go to NoScript Options -> Advanced Tab -> Abe Tab -> UNcheck "Enable ABE" It's kind of weird though, since You can see images loading, then disappear after complete.
Giorgio, are you still working on NoScript 3.5?
(In reply to Paul [pwd] from comment #39) > Giorgio, are you still working on NoScript 3.5? I'm maintaining it (for Android only) with the help of some volunteers who are also trying to backport updates from the desktop version. Speaking of which, I'm currently taking the opposite route to adapt desktop ("classic") NoScript, i.e. I'm trying to ensure that any new feature / fix is E10s aware, but I could port existent features in my spare cycles only: in facts I'm waiting for a certain funding request to be deliberated (within this month, they told me), which if granted would support an extraordinary full-time code sprint to port all the desktop version to native E10s in a reasonable time frame.
As was mentioned before ABE in latest NoScript 2.9.6 with e10s on nightly is a very buggy feature. If I try to download some file using direct link to it default download manager just hangs on 0 bytes trying to connect or something but fails. Download even can't be canceled till restart then it finally succeeds. Disabling ABE fixes this particular issue.
2 years ago
Just confirming, this still is occurring as of Aurora 41.0a2 today.
Now working in e10s: whitelist, blacklist, temporary allow (manual), embedding/plugin blocker. Always worked: auto page reload, UI & settings. Does not work: "Temporarily allow top-level sites by default". Not yet tested: XSS, force HTTPS, ABE, ClearClick.
(In reply to Frankie from comment #46) > > Does not work: "Temporarily allow top-level sites by default". > This has been fixed in 18.104.22.168, released last week.
The "XSS filtered" doorhanger never pops up on Aurora with 22.214.171.124 so I have to turn off the XSS filter whenever I want to do eBay searches. NoScript has always been overzealous about stripping the parens from searches like "(apple,mac) monitor cable". (An actual search I did recently to find a DA15 F-F cable for connecting my 4-way gameport switchbox to my SoundBlaster 16)
Ugh. Two corrections: First, that previous post was in reply to Frankie from comment #46. Second, DA15 M-M cable for the gameport switchbox, not F-F. (I'd just woken up)
Another issue: after dragging a whitelisted tab outside of it's window (to create a new Nightly window containing just that tab) - the noscript icon on the toolbar changes to the "page contains items that were blocked" icon, until you change to another tab and back again.
[Ubuntu 15.10, Firefox 43b, X86_64, Kernel 4.2.0-17, Radeon GFX card] Strange that I just encountered the 'noscript and e10' bug today for the first time. Yesterday noscript was seemingly working okay on 43b7... but upgrading to 43b8 has definitely stopped all noscript blocking. Not sure when e10 was turned on, but I definitely saw multiple Firefox processes in in 43b7, so I assume for some time. My NoScript is now at 2.7
(In reply to Andi from comment #51) > Yesterday noscript was seemingly working okay on 43b7... but upgrading to > 43b8 has definitely stopped all noscript blocking. NoScript's script blocking is currently e10s-compatible even on latest Nightlies. Are you testing with all your add-ons disabled except NoScript? If so, could you provide step-by-step instructions for reproducing? Thanks!
> NoScript's script blocking is currently e10s-compatible even on latest > Nightlies. As opposed to the "Temporarily allow top-level sites by default" part? Because that is what i'm experiencing with v2.7 - it does not seem to be fixed ( comment 47 ). Can you confirm that? I just synced my Firefox to DeveloperEdition (did the same at home with another profile) and setting this setting had no effect in either case.
(In reply to Nils from comment #54) > > NoScript's script blocking is currently e10s-compatible even on latest > > Nightlies. > > As opposed to the "Temporarily allow top-level sites by default" part? > Because that is what i'm experiencing with v2.7 - it does not seem to be > fixed ( comment 47 ). Can you confirm that? > > I just synced my Firefox to DeveloperEdition (did the same at home with > another profile) and setting this setting had no effect in either case. FYI, I reported this issue on NoScript's forum a little while back. https://forums.informaction.com/viewtopic.php?f=10&t=21450
(In reply to Nils from comment #54) > > NoScript's script blocking is currently e10s-compatible even on latest > > Nightlies. > > As opposed to the "Temporarily allow top-level sites by default" part? > Because that is what i'm experiencing with v2.7 - it does not seem to be > fixed ( comment 47 ). Can you confirm that? It's fixed in 2.9rc1, https://addons.mozilla.org/en-US/firefox/addon/noscript/versions/beta
Question: Is this bug checked against Firefox Stable yet?
For me its broken although granted I am using E10 on stable. (yes can be enabled). With E10 if I hover over the noscript icon all the domain specific options dont appear, I can just toggle global allow, revoke temporary permissions or enter the options screen, thats it, disable E10 and its back to normal. It was working a month or so ago.
(In reply to Chris from comment #58) > For me its broken although granted I am using E10 on stable. (yes can be > enabled). Same problem with the latest Beta.
Removing the WebExtensions-related blockers, adding the tab-switching bug 1246349 reported by :dholbert recently.
NoScript 126.96.36.199 works with e10s on Firefox 45.0 stable, at least on my end. Arch Linux
After upgrade to Nightly 14-04-2016 all webpages load very slowly, the whole browser including the interface hangs. Nightly is unusable. STR: Create new profile, install NoScript, restart, open new tab and go to http://www.yandex.ru ps Yandex is russian Google https://en.wikipedia.org/wiki/Yandex Result: this webpage and every other webpage I open loads very slowly, the whole browser hangs Expected result: webpages should load quickly and without hangs like with e10s disabled
(In reply to ajfhajf from comment #63) > After upgrade to Nightly 14-04-2016 all webpages load very slowly, the whole > browser including the interface hangs. Nightly is unusable. > > STR: > Create new profile, install NoScript, restart, open new tab and go to > http://www.yandex.ru > ps Yandex is russian Google https://en.wikipedia.org/wiki/Yandex > > Result: this webpage and every other webpage I open loads very slowly, the > whole browser hangs > Expected result: webpages should load quickly and without hangs like with > e10s disabled Which version of NoScript are you using, ajfhajf?
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #64) > Which version of NoScript are you using, ajfhajf? The latest available, 188.8.131.52. I also created a thread on the official NoScript forum: https://forums.informaction.com/viewtopic.php?f=10&t=21828 I'll do more testing in the near future because it seems to me that with AdBlock and NoScript the browser becomes even slower.
Seeing same behaviour on OS X 10.11 with 15-04-2016 build. Having NoScript enabled (184.108.40.206) renders whole browser unresponsive upon any page load. Happy to provide additional information if that helps debugging.
Hangs seem to be related to high CPU use by plugin-container.exe. This page was no problem.
Probably, browser hanging issue is Bug 1264896. if so, browser works normally under non-e10s.
Tried to reproduce on build 20160419030312, e10s. I did not notice relevant difference in responsiveness "upon any page load" (comment 66), nor on yandex.ru in particular (comment 63, no matter if with yandex.ru forbidden, by default, or allowed), NoScript installed vs. no add-on. I did notice, instead, that under memory pressure both page load times and UI responsiveness are severly impacted, which seems consistent with a GC-related issue. Maybe worth adding that Adblock Plus and NoScript are among the most memory-intensive add-ons, because of filtersets and whitelists respectively. I've got 16GB RAM on this machine, so the add-ons alone might not be enough to trigger memory-related bugs on me while doing it for some other user.
My machine has an Intel Xeon L5506@2.13 GHz (quad core) and 12Gb DDR3 memory. I'm running 64-bit Win 7. I've just updated to the current Nightly (19 Apr). Nightly doesn't work with both e10s and NoScript enabled. Pages take minutes to load, and even using browser features, e.g. Tools->Options, also takes inordinately long. If I disable e10s and leave NoScript running, everything's OK; enabling e10s and disabling NoScript produces the same result.
Thank you, Giorgio! I have 8 gigs of RAM. It looks like that if I go to about:memory and press GC, CC, "Minimize memory usage" then some webpages start to load with normal speed. However, some webpages still load slowly. After a couple of minutes all webpages start to load slowly again.
Sorry, I am wrong in the comment above: about:memory has nothing to do with performance improvements, yandex.ru hangs the browser on the first load but if you open yandex.ru again it loads almost instantly.
(In reply to dzobert from comment #66) I have the same issue. Enabling noscript means that opening a page causes Firefox to beach ball and require a kill -9. OS: OS X 10.11.4 Processor: 2.8 GHz Intel Core i7 RAM: 16G Browser: Firefox Dev Edition 48.0a2 (2016-05-04) Can provide extra info if requested.
(In reply to Amy Rich [:arr] [:arich] from comment #74) > (In reply to dzobert from comment #66) > > I have the same issue. Enabling noscript means that opening a page causes > Firefox to beach ball and require a kill -9. > > OS: OS X 10.11.4 > Processor: 2.8 GHz Intel Core i7 > RAM: 16G > Browser: Firefox Dev Edition 48.0a2 (2016-05-04) > > Can provide extra info if requested. I am surprised nobody answered your question earlier. NoScript performance has already been fixed in Nightly, take a look at the comments in this bug for more details: https://bugzilla.mozilla.org/show_bug.cgi?id=1264896 However, this bug hasn't been uplifted to Firefox Dev Edition 48 so now I see two options: 1. Wait for Firefox Dev Edition 49 release that will contain all the latest Nightly 49 bugfixes including the one that fixed NoScript performance 2. Switch to Nightly Maybe you can also ask developers to uplift this bug to Dev Edition 48 but I don't know how it's done.
NoScript 220.127.116.11 (current stable) is fully e10s-compatible and doesn't relies on any shim / CPOW anymore. Closing, feel free to reopen if new specific e10s-related issues surface.
More info: Noscript does not work with "normal" browser window nor with "e10s" browser window.
More info: Noscript does not work with "normal" browser window nor with "e10s" browser window.
It appears that somehow, "without warning", sometime today, NoScript "decided" to "Alow Scripts Globally". This happened on both the latest beta - 51.0b7 - with e10s off - and today's Nightly - 13 Dec - with e10s on!!! I then clicked on the icon to Block All Scripts (Recommended), and now it seems to be working correctly again, ad it apparently "remembered" my per-site settings. I can't imagine how this happened.
Sorry, I forgot to mention that I'm using NoScript 18.104.22.168 on both Fx versions.
Comments #78 - #81 appear to be unrelated to this bug and to e10s in general. @JoeG, if this consistently happens again, or you're otherwise able to reliably reproduce, please report at https://noscript.net/forum Thank you.