Using redirectUrl to a moz-extension URL in a webRequest.onBeforeRequest works on GVE and desktop, but not Fenix
Categories
(GeckoView :: Extensions, defect)
Tracking
(firefox79 fixed)
Tracking | Status | |
---|---|---|
firefox79 | --- | fixed |
People
(Reporter: twisniewski, Assigned: robwu)
References
Details
Attachments
(2 files)
3.19 KB,
patch
|
Details | Diff | Splinter Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
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.
Assignee | ||
Comment 1•5 years ago
|
||
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:
- Install/update Firefox Preview Nightly from the Play Store.
- Enable uBlock Origin.
- Attach a debugger via
about:debugging
on desktop (make sure to enable remote debugging on the phone and in Firefox Preview's settings first). - 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"]);
- Open example.com.
- 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)
Reporter | ||
Comment 2•5 years ago
|
||
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.
Reporter | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
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.
Assignee | ||
Comment 4•5 years ago
|
||
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.
Assignee | ||
Comment 5•5 years ago
|
||
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
Updated•5 years ago
|
Comment 7•5 years ago
|
||
bugherder |
Description
•