Closed Bug 1246349 Opened 9 years ago Closed 8 years ago

[e10s] With NoScript installed, changing tabs between pinned-tab & non-pinned tab can trigger zillions of "unsafe CPOW usage" (and tabstrip position / site-ID area doesn't reliably update)

Categories

(WebExtensions :: General, defect, P1)

defect

Tracking

(e10s+, firefox48- unaffected, firefox50+ wontfix)

RESOLVED FIXED
Tracking Status
e10s + ---
firefox48 - unaffected
firefox50 + wontfix

People

(Reporter: dholbert, Assigned: ma1)

References

Details

(Whiteboard: triaged)

Attachments

(3 files)

STR:
 0. Start with a fresh Firefox profile (optional)
 1. Install NoScript (I've got version 2.9.0.3)
 2. Open 30-40 new tabs (so that your tabstrip overflows by a good amount)
 3. Pin 5 tabs.
 4. Open Browser Console (Ctrl+Shift+J). Hit "clear" so that new errors are obvious.
 5. Focus one of your pinned tabs, and try changing tabs with "Ctrl+PageUp" and "Ctrl+PageDown".  In particular, try walking off the left & right edges of the list of pinned tabs.

(See attached screencast)

EXPECTED RESULTS:
 - Tab strip should always update to show the focused tab. 
 - No errors in error console.

ACTUAL RESULTS:
- Sometimes (not always, but often) the tabstrip will fail to update to show the focused tab -- this is usually when I've used "Ctrl+PageUp" to walk off the right edge of my Pinned Tabs.
 - When this happens, I see one or more copies of these errors in my browser console:
> unsafe CPOW usage                      noscriptOverlay.js:2449:14
> Error: unsafe CPOW usage forbidden     tabbrowser.xml:505:19
If I click on the source-link on the right side of the first console error (for noscriptOverlay.js), it takes-me to a view-source view with the last line here highlighted (const domWindow):

    webProgressListener: {
      QueryInterface: noscriptUtil.service.generateQI([Ci.nsIWebProgressListener]),
      STATE_STOP: Ci.nsIWebProgressListener.STATE_STOP,
      onLocationChange: function(aWebProgress, aRequest, aLocation) {
        const domWindow = aWebProgress && aWebProgress.DOMWindow;


The second error (with a link to tabbrowser.xml) is is less obviously-usefu -- it's the last line here, with "reportError(e)":


      <method name="_callProgressListeners">
      [...]
          function callListeners(listeners, args) {
            for (let p of listeners) {
              if (aMethod in p) {
                try {
                  if (!p[aMethod].apply(p, args))
                    rv = false;
                } catch (e) {
                  // don't inhibit other listeners
                  Components.utils.reportError(e);

I'm guessing that's an "echo" from the first error being reported at a higher level, or something.
Summary: With NoScript installed, changing tabs between pinned-tab & non-pinned tab can trigger zillions of "unsafe CPOW usage" (and tabstrip doesn't update to show focused tab) → [e10s] With NoScript installed, changing tabs between pinned-tab & non-pinned tab can trigger zillions of "unsafe CPOW usage" (and tabstrip doesn't update to show focused tab)
As you can see in the screencast, usually when I Ctrl+PageUp off of the right side of the pinned tabs (to focus the first non-pinned tab), the first-non-pinned tab is *completely invisible* when it receives focus.  (e.g. at 0:04 - 0:10 in the screencast)

Other times, if the tabstrip is scrolled to just the right position, the first-non-pinned-tab may be partially (but not entirely visible) when it receives focus. (e.g. at 0:12-0:16 in the screencast)
Attachment #8716581 - Attachment description: screencast of bug → screencast of tabstrip not being scrolled to correct position
Much worse (from a security perspective) aspect of this bug -- the site identity button doesn't reliably update when I Ctrl+PageUp/PageDown across the threshold between pinned tabs & non-pinned tabs.

I'm guessing it's the same problem -- we're simply throwing an exception and bailing before we've finished doing all of the work-that-needs-to-happen-to-handle-a-tab-change.

STR for this experiment are the same as in comment 0, except that I've made my rightmost pinned tab https://www.facebook.com/ (note its green EV lock icon) and my first non-pinned tab http://example.org/  (note that this is NOT a HTTPS site)

If I (re)load Facebook, it shows its green EV lock. Then I Ctrl+PageDown to switch to example.org -- and as you can see in the screencast, *the green lock sticks around* despite the fact that I've got an insecure connection there.

This is bad.
Attachment #8716582 - Attachment description: screencast of site identity button (green "secure" lock) not being updated as I change tabs → screencast of site identity button (green "secure" lock) not being added/removed as I change from HTTPS to non-HTTPS tabs
Summary: [e10s] With NoScript installed, changing tabs between pinned-tab & non-pinned tab can trigger zillions of "unsafe CPOW usage" (and tabstrip doesn't update to show focused tab) → [e10s] With NoScript installed, changing tabs between pinned-tab & non-pinned tab can trigger zillions of "unsafe CPOW usage" (and tabstrip position / site-ID area doesn't reliably update)
Not sure if this is purely a NoScript bug, or a browser bug as well. (Seems like this is something that our tab-switching code should be robust against, but maybe it can't be?)

I'm classifying this as Tech Evang|Add-ons for now and tagging Giorgio to take a look when he can -- but billm, feel free to spin off a Firefox bug, too, if you think one would be merited.
Flags: needinfo?(g.maone)
Also: all symptoms here seem to be a bit intermittent -- I can't always trigger them reliably, but I usually hit them within a few minutes from switching between tabs using Ctrl+PageUp/PageDown and clicking around among my tabs.  Once I've gotten into the broken state.

Also, there's one more thing that's failing to update here -- the window's title bar. e.g. at time 0:06 in my second screencast (attachment 8716582 [details]), I've switched to the example.org tab, but my title bar still says Facebook.
Forgot to mention, I'm using latest 64-bit Nightly 47.0a1 (2016-02-05) on Ubuntu 15.10, with latest NoScript available from about:addons searchbox (version 2.9.0.3 as noted in comment 0).
Daniel, thank you for the very detailed report. I believe I know what's going on (parent process-side webProgressListeners not getting any meaningful DOMWindow when e10s is enabled) even though I believe that it (used to be) shimmed and that a failing listener should not break the browser's own flow anyway.
However, I think I can fix it in on my side and I'm going to do it ASAP.
Flags: needinfo?(g.maone)
Assignee: nobody → g.maone
Blocks: e10s-addons
tracking-e10s: --- → +
See Also: → 1246077
Giorgio, any ETA on a fix here?
Flags: needinfo?(g.maone)
(In reply to Daniel Holbert [:dholbert] from comment #10)
> Giorgio, any ETA on a fix here?

More a work-around than a fix, most likely next week.
Flags: needinfo?(g.maone)
(In reply to Giorgio Maone [:mao] from comment #11)
> (In reply to Daniel Holbert [:dholbert] from comment #10)
> > Giorgio, any ETA on a fix here?
> 
> More a work-around than a fix, most likely next week.

Any updates on how this is going?
Flags: needinfo?(g.maone)
I did have a patch which needed some more tweaking when I was suddenly struck with multiple emergengies: a Nightly change completely breaking NoScript, which could not even be started up, a patch needed for a security issue about to be disclosed, and some XSS filter bypasses which required real-time fixes.

Now that the waters are relatively calmer, I should be able to finish by this week and release publicly in the beginning of the next.
Flags: needinfo?(g.maone)
As additional effects, I will add bug 1274592 that have been dupe of another bug itself dupe of this one but seems related.
Bug 1274594 seems to happens in the same time and to be related.

Finally, a last effect I noticed having no bug:
- If you close cleanly the browser with several tabs opened and having selected another one than the first one of the tabstrip
- Then you reopen it and choose to restore the session
- Finally select the first tab of the tabstrip

This tab will not reload and content will remains blank. You need to force it by validating the URL a new time.

All of this seems related to the presence of both NoScript and activation of e10s in the same time.

Giorgio, have you noticed such behaviors?
Flags: needinfo?(g.maone)
[Tracking Requested - why for this release]: Carrying over nomination flags from the duplicate bug.
Tracking this for 50 but not for 48/49 since the early e10s rollout, at least in 48, won't happen for anyone with addons installed.
reach out to giorgio when he's back
Flags: needinfo?(sescalante)
Another thing that will be probably duped to this, so I'm mentioning it directly here is NoScript+e10s breaking Reload/Stop button:

1) Open 3 or more tabs (one preferably with some site that takes a while to reload)
2) Hit reload and switch to another tab _before_ the reload finishes
3) Result: Reload/Stop button stuck in Stop state until you switch back to the tab you reloaded (ie you can switch between other tabs and it will stay stuck).
Flags: needinfo?(sescalante)
Priority: -- → P1
Whiteboard: triaged
NoScript 2.9.5 gets completely rid of any CPOWs usage and is fully e10s compatible. I'm working around the clock to release it before the end of this month.
Flags: needinfo?(g.maone)
(In reply to Giorgio Maone [:mao] from comment #23)
> NoScript 2.9.5 gets completely rid of any CPOWs usage and is fully e10s
> compatible. I'm working around the clock to release it before the end of
> this month.
Do you expect NoScript 2.9.5 with e10s activated might sometimes be slower than NoScript 2.9.5 with e10s disabled? That's the case with AdBlock which is currently using the synchronous content blocking API:
https://bugzilla.mozilla.org/show_bug.cgi?id=1280368#c1
I hope I will soon be able to check that out myself, though.
(In reply to ajfhajf from comment #24)
> Do you expect NoScript 2.9.5 with e10s activated might sometimes be slower
> than NoScript 2.9.5 with e10s disabled? That's the case with AdBlock which
> is currently using the synchronous content blocking API:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1280368#c1

No, I don't expect any issue like that because NoScript 2.9.5 is synchronizing the relevant state across processes on permissions changes, therefore there will be no need for cross-process synchronous messaging on content blocking decisions.
Hi Giorgio, Fx50 is planned to go-live Nov 15th. Do you think NoScripts v2.9.5 will be released before that? Just wondering.
Flags: needinfo?(g.maone)
(In reply to Ritu Kothari (:ritu) from comment #26)
> Hi Giorgio, Fx50 is planned to go-live Nov 15th. Do you think NoScripts
> v2.9.5 will be released before that?
Yes, that's the plan.
Flags: needinfo?(g.maone)
I've just released 2.9.5rc21 in the Beta channel,
https://addons.mozilla.org/firefox/downloads/file/536092/noscript_security_suite-2.9.5rc21-fx+sm.xpi

It's completely rid of any CPOW usage and doesn't seem to exhibit the odd tab synchronization behavior.
I'm still looking for possible regressions, but unless some egregious showstopper is found I'd like to release 2.9.5 stable on Monday.
(In reply to Giorgio Maone [:mao] from comment #28)
> I've just released 2.9.5rc21 in the Beta channel
It looks like I found a bug. STR:
Nightly 2016-11-12, NS 2.9.5rc21. Create new profile, install 2.9.5rc21 from AMO
Go to about:config, find capability.policy.maonoscript.sites and replace its value with the string from this pastebin: http://pastebin.com/B1zMDHv7
Go to https://www.instagram.com/advokatzhorin/
Hover the mouse over NoScript icon: it says "Forbid Instagram", "Forbid akamaihd.net", that means instagram and akamaihd are whitelisted. However, both scripts from both instagram and akamaihd are actually blocked by NoScript.
Another bug. Nightly 2016-11-12, NS 2.9.5rc21. Create new profile, install 2.9.5rc21 from AMO, drag "Revoke temporary permissions" button to the navigation bar. Close Nightly, launch Nightly. "Revoke temporary permissions" button is active though it shouldn't be.
(In reply to ajfhajf from comment #29)
> (In reply to Giorgio Maone [:mao] from comment #28)
> > I've just released 2.9.5rc21 in the Beta channel
> It looks like I found a bug.

Please don't use to this Bugzilla entry for further unrelated bug reports about 2.9.5 release candidates, but rather open one thread per issue here: https://forums.informaction.com/viewforum.php?f=10
Thank you.
NoScript 2.9.5.1 (current stable) is fully e10s-compatible and doesn't relies on any shim / CPOW anymore.
Closing, feel free to reopen if symptoms are still reproducible.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Component: Add-ons → General
Product: Tech Evangelism → WebExtensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: