Open Bug 1826867 Opened 2 years ago Updated 1 year ago

Reloading an extension page that was redirected causes "Access to the file was denied"

Categories

(WebExtensions :: Request Handling, defect, P2)

Product:
WebExtensions
Component:
Request Handling
Version:
Firefox 111
Type:
defect

Tracking

(firefox112 affected, firefox113 affected)

Tracking Flags:
Tracking Status
firefox112 --- affected
firefox113 --- affected

People

(Reporter: lucalli2000+bugzilla, Unassigned)

References

Details

(Whiteboard: [addons-jira])

Attachments

(1 file)

extension.zip
753 bytes, application/x-zip-compressed
Details
Attached file extension.zip —

Steps to reproduce:

Using an extension, inside the listener for onHeadersReceived, redirect any request to an extension page (moz-extension://).
After the redirect happened, reload the page (F5).

  1. run the extension i attached using "web-ext run"
  2. go to the extension settings and give the extension host permissions for any url
  3. visit https://example.com
  4. reload the page

Extension code:

// background.js browser.webRequest.onHeadersReceived.addListener(() => { return {redirectUrl: browser.runtime.getURL("test.html")} }, { urls: ["*://*/*"], }, ["blocking"]);

// test.html <!doctype html> <html lang="en"> <head> <title>Document</title> </head> <body> Hello World! </body> </html>

// manifest.json { "manifest_version": 3, "version": "1", "name": "test", "permissions": [ "webRequest", "webRequestBlocking" ], "host_permissions": [ "<all_urls>" ], "background": { "scripts": [ "background.js" ] }, "web_accessible_resources": [ { "resources" : [ "test.html" ], "matches" : [ "*://*/*" ] } ] }

Actual results:

On first load, the extension page gets rendered.
On reload the error "Access to the file was denied" gets shown and the extension page cannot be rendered anymore.

Furthermore, it shows:
The file at /C:/<project-path>/test.html is not readable.
It may have been removed, moved, or file permissions may be preventing access.

Expected results:

On reload, the extension page should still be rendered.

If you manually copy the link to the extension page (in my case:
moz-extension://0fd8b6b1-b983-480f-aea4-43e8af8dd92a/test.html), the reload works perfectly fine.

Hello,

I reproduced the issue on the latest Nightly (113.0a1/20230409095525), Beta (112.0/20230406114409) and Release (111.0.1/20230321111920) under Windows 10 x64 and macOS11.3.1.

After accessing https://example.com, the extension page gets rendered, however, upon page reload, the page is no longer rendered and the "Access to the file was denied" error is shown, as per Comment 0.

However, the above behavior I observed to be happening when loading the manifest.json file of the unpacked extension via about:debugging.

Loading the entire .zip via about:debugging will no longer cause the page to not render upon page reload.

Status: UNCONFIRMED → NEW
status-firefox112: --- → affected
status-firefox113: --- → affected
Ever confirmed: true

Somehow the URI associated with the nsIHistoryEntry is the file:-URL instead of the moz-extension:-URL (It is a file:-URL because files within temporarily loaded extensions resolve to the underlying file on disk; for packed extensions it would resolve to jar:-URIs). I would expect a moz-extension:-URI instead (which should resolve to file/jar as needed on refresh).

  • Cmd (run in the global browser console after visiting example.com that redirects to the moz-extension:-URL): gBrowser.selectedBrowser.browsingContext.sessionHistory.getEntryAtIndex(gBrowser.selectedBrowser.browsingContext.sessionHistory.index)
  • Actual result: "file:///private/tmp/repro/test.html"
  • Expected: moz-extension://b0d08b69-57d0-4f7b-a962-67382bd14bd4/test.html

Command that produces the output below (logs captured after reloading the example.com->moz-extension redirected page):

MOZ_LOG=SessionHistory:5 web-ext run -v -u https://example.com -f /path/to/gecko/objdir-debug/dist/NightlyDebug.app/Contents/MacOS/firefox

[Child 80516: Main Thread]: D/SessionHistory Moving the loading entry to the active entry on nsDocShell 111043000 to file:///private/tmp/repro/test.html
[Parent 80513: Main Thread]: V/SessionHistory CanonicalBrowsingContext::SessionHistoryCommit 14b4a3c00 39
[Parent 80513: Main Thread]: V/SessionHistory SHEntry::RemoveLoadId(39)
[Parent 80513: Main Thread]: D/SessionHistory nsSHistory 1117fa4c0
[Parent 80513: Main Thread]: D/SessionHistory +- 0 SH Entry 14b5fe780 36 {5657d34b-e4ba-4009-9ed5-832c9e07f6a7}
[Parent 80513: Main Thread]: D/SessionHistory | URL = about:newtab
[Parent 80513: Main Thread]: D/SessionHistory | Title = New Tab
[Parent 80513: Main Thread]: D/SessionHistory | Name =
[Parent 80513: Main Thread]: D/SessionHistory | Is in BFCache = false
[Parent 80513: Main Thread]: D/SessionHistory >+- 1 SH Entry 146157300 47 {5657d34b-e4ba-4009-9ed5-832c9e07f6a7}
[Parent 80513: Main Thread]: D/SessionHistory URL = file:///private/tmp/repro/test.html
[Parent 80513: Main Thread]: D/SessionHistory Title = Document
[Parent 80513: Main Thread]: D/SessionHistory Name =
[Parent 80513: Main Thread]: D/SessionHistory Is in BFCache = false

Packed xpi, similar start but different URL/Title:

[Parent 80513: Main Thread]: D/SessionHistory +- 0 SH Entry 14be13300 41 {fee0502d-fc90-43b2-9cee-e6fc578c74d0}
[Parent 80513: Main Thread]: D/SessionHistory | URL = about:newtab
[Parent 80513: Main Thread]: D/SessionHistory | Title = New Tab
[Parent 80513: Main Thread]: D/SessionHistory | Name =
[Parent 80513: Main Thread]: D/SessionHistory | Is in BFCache = false
[Parent 80513: Main Thread]: D/SessionHistory >+- 1 SH Entry 13e827c80 56 {fee0502d-fc90-43b2-9cee-e6fc578c74d0}
[Parent 80513: Main Thread]: D/SessionHistory URL = jar:file:///private/tmp/repro/x.xpi!/test.html
[Parent 80513: Main Thread]: D/SessionHistory Title = jar:file:///private/tmp/repro/x.xpi!/test.html
[Parent 80513: Main Thread]: D/SessionHistory Name =
[Parent 80513: Main Thread]: D/SessionHistory Is in BFCache = false

And for the record, the file:-load is denied, with the following stderr output on debug builds:

[Child 80455, StreamTrans #7] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED): file /path/to/gecko/netwerk/base/nsFileStreams.cpp:509

The severity field is not set for this bug.
:robwu, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(rob)

We should at least understand what is going on, given the observations in comment 2.

Severity: -- → S3
Flags: needinfo?(rob)
Priority: -- → P2
Whiteboard: [addons-jira]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: