1645264 - Using redirectUrl to a moz-extension URL in a webRequest.onBeforeRequest works on GVE and desktop, but not Fenix

Status: RESOLVED FIXED

(GeckoView :: Extensions, defect)

Description

[Thomas Wisniewski [:twisniewski] [on PTO until Sep.9]]

While working on bug 1637329, I've found that redirecting network requests (using a standard extension webRequest.onBeforeRequest blocking listener) to a moz-extension: URL bundled with the addon does not work in a local Fenix build (though it does work in the embedded geckoview browser and on desktop builds).

I receive this error in the script console:

<script> source URI is not allowed in this document: (URL being loaded)

This error is logged from here: https://searchfox.org/mozilla-central/source/dom/script/ScriptLoader.cpp#3555

And I've traced the source of the NS_ERROR_DOM_BAD_URI to here: https://searchfox.org/mozilla-central/source/netwerk/protocol/http/HttpChannelChild.cpp#2163
(As changing the error code returned there changes the console error which is logged).

I'm not sure what this means, since it's only happening for me in Fenix and not the embedded Geckoview browser (the above code is not reached when I run the same extension code in the GVE browser or a desktop build).

It may also be worth noting that I've tried toggling extensions.webextensions.remote to true, but that did not change the result.

Comment 1

[Rob Wu [:robwu]]

Could you provide steps to reproduce this problem? Is this just your local build (and if so, which base commit) or also on an official build?

I am unable to reproduce this on Firefox Preview Nightly (Nightly 200611 06:01 (Build #21630608), 45.0.20200610130052, e5839f921, GV 79.0a1-20200609092134, AS 60.0.0 - as seen at Settings > About Firefox Nightly).

I tried the following STR:

1. Install/update Firefox Preview Nightly from the Play Store.
2. Enable uBlock Origin.
3. Attach a debugger via about:debugging on desktop (make sure to enable remote debugging on the phone and in Firefox Preview's settings first).
4. Inspect uBlock Origin's background page (because it has access to the webRequest API, plus embeds web_accessible_resources). Run the following snippet:

browser.webRequest.onBeforeRequest.addListener(d => {
  console.log(d);
  return { redirectUrl: browser.runtime.getURL("web_accessible_resources/chartbeat.js"), };
}, {
  urls: ["*://*/*redirme*"],
}, ["blocking"]);

5. Open example.com.
6. Inspect example.com via about:debugging and run the following script:

var s = document.createElement("script");
s.src = "http://example.org/redirme";
s.onload = () => { console.log(pSUPERFLY); };
document.body.append(s);

Expected result & actual result:

• The console at the last step shows an object with noopfn functions (from https://github.com/gorhill/uBlock/blob/caa8e7d35ba61214a9d13e7d324b2bd2aa73237f/src/web_accessible_resources/chartbeat.js#L26-L28)

Comment 2

[Thomas Wisniewski [:twisniewski] [on PTO until Sep.9]]

Attachment: test.patch

What I did was to make a local build of Fenix, with a local copy of Android Components using this patch I am attaching which just adds a basic listener as a reduced test-case. The Fenix and A-C branches are from yesterday, so I suppose they may be more up-to-date than what's running on the Fenix nightlies?

At any rate, I started up that build in the Android Studio emulator and visited the test-page https://thomas.tanrei.ca/moz/test.html. Checking the multiprocess toolbox console in the remote devtools, the console reads:

12:05:47.697 REDIRECTING shims.js:10:9
12:05:47.714 <script> source URI is not allowed in this document: “https://thomas.tanrei.ca/moz/test.js”. test.html:4:1

I would expect it to either have BAD (if the redirect did not happen at all) or TEST SHIM WORKED! if the redirect worked as expected.

Comment 3

[Rob Wu [:robwu]]

This issue is caused by the fact that registerWebExtension passes a resource:-URL to the Extension constructor.
This causes moz-extension:-requests from content to break, because the ExtensionProtocolHandler only accepts jar: and file: URLs (not resource:).

If Android-Components used the installBuiltIn method to install extensions instead of registerWebExtension (the latter is deprecated - bug 1634504), then this bug wouldn't have happened. Tom mentioned that it may take a while for A-C to migrate, so I'm going to fix this issue here in the interest of unblocking work on the webcompat add-on.

Comment 4

[Rob Wu [:robwu]]

Attachment: Bug 1645264 - Add test for redirect to web_accessible_resources

The new unit test currently uses the deprecated registerWebExtension
method (to verify the fix for the bug). When the deprecated method is
removed, the test can still continue to serve as a regression test.

Comment 5

[Rob Wu [:robwu]]

I chatted with Agi, and he prefers to not change the implementation of registerWebExtension since it barely has test coverage.
Apparently A-C is close to replacing registerWebExtension with installBuiltin, so this bug would be fixed by that.

I'll repurpose this bug/patch to add a regression test.

The actual fix depends on https://github.com/mozilla-mobile/android-components/issues/6356

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cc6a9d8f2918
Add test for redirect to web_accessible_resources r=agi,geckoview-reviewers

Comment 7

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/cc6a9d8f2918