1880735 - MV3 extension blank Options page

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, defect)

Description

[Tom Doan]

Attachment: my-mv3-ext.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0

Steps to reproduce:

1. Unzip my-mv3-ext.zip (attached) to any folder
2. Go to about:debugging#/runtime/this-firefox
3. Click "Load Temporary Add-on" and select manifest.json in the zip
4. Open the Options page of this extension

Here is a screen recording: https://www.loom.com/share/3d60b00441ba487fb7a627e176ac0309

Actual results:

Blank page.

Expected results:

It should open the Options page.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Rob Wu [:robwu]]

The screen recording shows that the add-on was loaded from R:/my-mv3-ext/ . Is there anything special about this R: drive? Is it a regular disk, a network share, etc?

Can you also share the output of about:support?

I guess that the issue is independent of MV3 or options page, and that the same issue would also happen if you tried to use it as a regular tab or even an extension panel: "action": {"page":"options.html"}. Can you give it a try and confirm that the same issue is happening?

This reminds me of bug 1827656, because that emphasizes that temporarily loaded add-ons can be affected by filesystem-specific issues:

When an extension is loaded temporarily from the local filesystem, paths are resolved according to the rules of the local filesystem.

Comment 3

[Alex Cornestean]

Hello,

I could not reproduce the issue on the latest Nightly (125.0a1/202402192122), Beta (124.0b1/20240219092531) or Release (123.0/20240213221259) under Windows 10 x64 or Ubuntu 22.04 LTS.

I loaded the extension in about:debugging, both as the entire .zip file as well as only the manifest.json and when opening the Options page, an “OPTIONS” header is displayed. Checking the page source also shows the html code used.

Note that I loaded the extension from a folder on Desktop.

For more details, see the attached screenshots.

Comment 4

[Alex Cornestean]

Attachment: 2024-02-20_10h21_27.png

Comment 5

[Alex Cornestean]

Attachment: 2024-02-20_10h10_51.png

Comment 6

[Alex Cornestean]

Attachment: 2024-02-20_10h11_02.png

Comment 7

[Tom Doan]

Rob, your suspicions were correct: I was loading the extension from a RAM disk managed by ImDisk Toolkit. After re-loading the extension from my local hard drive, it works as expected. It's good to know about this limitation, although note that Chrome doesn't have this limitation (i.e., I can load unpacked extensions from the RAM disk).

Please let me know if I can close this as WONTFIX, unless you do plan to remove this limitation.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.

Comment 9

[Rob Wu [:robwu]]

This is not a supported configuration.

When I tested this configuration locally, I noticed that the main process can load the file just fine, but not when loaded from a content process.