uBlock Origin + a WebExtension's webRequest.onErrorOccurred listener = page load hanging

VERIFIED FIXED in Firefox 52

Status

()

Toolkit
WebExtensions: Request Handling
VERIFIED FIXED
a year ago
a year ago

People

(Reporter: u287251, Assigned: kmag)

Tracking

53 Branch
mozilla53
x86_64
Linux
Points:
---

Firefox Tracking Flags

(firefox51 unaffected, firefox52 verified, firefox53 verified)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

a year ago
Created attachment 8813453 [details]
webext-onerroroccurred.zip

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20161122030216

Steps to reproduce:

This issue was first reported on my issue tracker[1]. Eventually, I narrowed the steps to reproduce as follow:

1. Launch Nightly.
2. Install uBlock Origin ("uBO")  (default settings will do).
3. Open a new tab, load with https://tweetdeck.twitter.com/
4. Observation: the page load fine, with two scripts blocked by uBO:
  - ton.twimg.com/tweetdeck-web/web/scripts/google_analytics.4a354c1e82.js
  - ssl.google-analytics.com/ga.js
5. Go to about:debugging
6. Load the very simple webextension provided as attachment [2].
7. Force a reload of the tab which URL is https://tweetdeck.twitter.com/
8 Observation: the page load hangs, with the spinner image never going away.

More observations:

The page load hang issue does NOT occur if...

- ... I remove either
    - chrome.webRequest.onBeforeSendHeaders.addListener; OR
    - chrome.webRequest.onErrorOccurred.addListener
  from the background.js file of the minimalist webextension.

- ... the "blocking" option is not used.

- ... the webextension is loaded *before* uBO is enabled, so it appears the order of the HTTP observers is key (uBO registers its own HTTP observer).

- ... the webextension version of uBO is used.

- ... if only the script ton.twimg.com/tweetdeck-web/web/scripts/google_analytics.4a354c1e82.js is NOT blocked by uBO.

Notes:

The issue also occurred when using chrome.webRequest.onBeforeRequest instead of chrome.webRequest.onBeforeSendHeaders.

***

[1] https://github.com/gorhill/uBlock/issues/2173

[2] The ZIP file consist of two small files, a valid webext extension:

manifest.json:

    {
        "name": "Bugzilla",
        "version": "1.0",
        "permissions": ["webRequest", "webRequestBlocking"],
        "background": {
            "scripts": ["background.js"]
        },
        "applications": {
            "gecko": {
                "id": "pageloadhang@webextensions"
            }
        },
        "manifest_version": 2,
        "description": "Bugzilla"
    }

background.js:

    chrome.webRequest.onBeforeSendHeaders.addListener(
        function() {},
        {urls:["<all_urls>"]},
        ["blocking"]
    );
    chrome.webRequest.onErrorOccurred.addListener(
        function() {},
        { urls:["<all_urls>"]}
    );
(Reporter)

Updated

a year ago
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
(Reporter)

Comment 1

a year ago
Created attachment 8813730 [details]
bugzilla1319607-bootstrapped.zip
(Reporter)

Comment 2

a year ago
Created attachment 8813731 [details]
bugzilla1319607-webextension.zip
Attachment #8813453 - Attachment is obsolete: true
(Reporter)

Comment 3

a year ago
I have create a minimalist bootstrapped extension, to use instead of using uBlock Origin.

The minimalist bootstrapped extension has only ONE purpose: to cancel a network request for the resource which URL is https://ton.twimg.com/tweetdeck-web/web/scripts/google_analytics.4a354c1e82.js.

I amended the minimalist webextension to change its name to make clear its related to the issue here.

Once both minimalist extensions are loaded through about:debugging, it's just a matter of clicking the "Reload" button of one or the other extension to make the issue appear/disappear:

- test case: https://tweetdeck.twitter.com/
- if the bootstrapped extension is loaded after the webextension one = page does not hang.
- if the webextension extension is loaded after the bootstrapped one = page does hang.
(Reporter)

Comment 4

a year ago
For the record, this also occurs with Ghostery 7.0.14[1]. Looking at the source code, I confirm this is related to the issue here, Ghostery is a webextension, and registers a webRequest.onErrorOccurred listener.

[1] https://addons.mozilla.org/en-US/firefox/addon/ghostery/

Updated

a year ago
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
Your bootstrapped add-on breaks web requests on its own, since it registers a channel event sink and doesn't provide an asyncOnChannelRedirect method. After fixing that, though, I see the problem.
Assignee: nobody → kmaglione+bmo
Status: UNCONFIRMED → NEW
status-firefox51: --- → unaffected
status-firefox52: --- → affected
status-firefox53: --- → affected
Ever confirmed: true
Comment hidden (mozreview-request)

Comment 7

a year ago
mozreview-review
Comment on attachment 8814242 [details]
Bug 1319607: Make request resumption more resilient.

https://reviewboard.mozilla.org/r/95476/#review95746
Attachment #8814242 - Flags: review?(mixedpuppy) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/5b45f7938182ea8bf814ab0bb6373bcf803755b5
Bug 1319607: Make request resumption more resilient. r=mixedpuppy
Comment on attachment 8814242 [details]
Bug 1319607: Make request resumption more resilient.

Approval Request Comment
[Feature/regressing bug #]: Bug 1254204
[User impact if declined]: This bug causes some requests to never fully complete, and therefore some pages to never fully load, when certain request blocking extensions are installed alongside each other.
[Describe test coverage new/current, TreeHerder]: This feature has extensive existing tests, and new tests have been added for this issue.
[Risks and why]: Low. This is a minimal change to make sure that cleanup code is called in more corner cases.
[String/UUID change made/needed]: None.
Attachment #8814242 - Flags: approval-mozilla-aurora?

Comment 10

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/5b45f7938182
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox53: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53

Comment 11

a year ago
Latest Nightly 53.0a1 (2016-11-26) fixed this issue, thanks!
Comment on attachment 8814242 [details]
Bug 1319607: Make request resumption more resilient.

request resumption fix, take in aurora52

note that "Only resume the channel if either it was suspended by this call." could probably lose the "either", since the "or" part was removed :)
Attachment #8814242 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 13

a year ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/9dd3c365bc5d
status-firefox52: affected → fixed
(In reply to Julien Cristau [:jcristau] from comment #12)
> note that "Only resume the channel if either it was suspended by this call."
> could probably lose the "either", since the "or" part was removed :)

Ah. Quite. Good catch.
https://hg.mozilla.org/integration/mozilla-inbound/rev/ea74e14fae4134d3f3c1a0098f9bda5695a7ada6
Bug 1319607: Follow-up: Fix typo.
https://hg.mozilla.org/releases/mozilla-aurora/rev/bb32677bad4c

Comment 17

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/ea74e14fae41
I was able to reproduce this issue on Firefox 53.0a1 (2016-11-22) under Windows 10 64-bit.

Verified fixed on Firefox 53.0a1 (2016-11-29) and Firefox 52.0a2 (2016-11-29) under Windows 10 64-bit and Ubuntu 16.04 32-bit. The page is instantly loaded.
Status: RESOLVED → VERIFIED
status-firefox52: fixed → verified
status-firefox53: fixed → verified
You need to log in before you can comment on or make changes to this bug.