1949092 - <input type="file"> is not functionable in an options page embedded in the add-ons manager (about:addons)

Status: VERIFIED FIXED

(WebExtensions :: Frontend, defect, P1)

Description

[YUKI "Piro" Hiroshi]

Attachment: testcase.xpi: the testcase with an options page containing file field

Abstract

File type input field (<input type="file">) does not work in an options page embedded in the add-ons manager (about:addons) page.
This problem was originally reported at https://github.com/piroor/treestyletab/issues/3707

Steps to reproduce

1. Download the attached testcase XPI.
2. Go to about:debugging and load the testcase XPI as a temporary extension.
3. Go to about:addons.
4. Choose the addon "testcase".
5. Choose the "Options" tab.
6. Click the "Browse..." button in the options page.

Actual result

Nothing happens.

Expected result

A file chooser dialog appears.

Environment

• Nightly 137.0a1 (build ID: 20250218205441) on Windows 11 24H2
• Firefox 136.0b7 (build ID: 20250217120651) on Windows 11 24H2

Additional information

This does not happen on Firefox 135.0.

Comment 1

[Rob Wu [:robwu]]

mozregression points to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1fe06d3ac98b2ab9be5fb354e6595f819004b10c&tochange=e49da4b8b2d09f51ba9072863281bbc23e787c0a

Comment 3

[Rob Wu [:robwu]]

To see what is happening, between step 5 and 6 of the STR, run the following snippet from the devtools (in the about:addons tab). In comments, I wrote the current output:

setTimeout(() => {
  let browser = document.querySelector("browser#addon-inline-options");
  let bc = browser.browsingContext;
  let chromeDoc = bc.topChromeWindow.document; // the browser.xhtml, as expected
  console.log(
    bc.canOpenModalPicker, // = false, which causes this bug (bug 1949092)
    chromeDoc.activeElement, // = about:addons browser (tab browser)
    bc.topFrameElement // == browser, i.e. the browser#addon-inline-options
  );
}, 3000);

The above shows that the logic at https://searchfox.org/mozilla-central/rev/0d1f8ff61fe506646fe3898ef727817b4436ab32/docshell/base/CanonicalBrowsingContext.cpp#3271,3285,3294 does not account for the special situation in about:addons, where a <browser> is embedded in tab content (source of browser#addon-inline-options).

Comment 4

[Rob Wu [:robwu]]

Since I have a good understanding of what is going on, I'm going to work on a patch.

Comment 5

[Rob Wu [:robwu]]

This issue is not limited to the options page, by the way. It also affects the sidebar.
To see this, install the tree-style tabs add-on (which opens the sidebar), and run the snippet from comment 3 in the global Browser Console, with the second replaced with:

let browser = document.querySelector("browser#sidebar").contentDocument.querySelector("browser#webext-panels-browser");

then click inside the sidebar to focus it. The output is:

• bc.canOpenModalPicker = false
• chromeDoc.activeElement = browser#sidebar
• bc.topFrameElement = browser, i.e. the browser#webext-panels-browser

This shows that the logic from the regressor does not account for non tab browsers.

P.S. For completeness, I also verified what happens with extension popup panels. Their <browser> are non-tab browsers, but still embedded in the top level. It works as expected. To test that, use the snippet with let browser = document.querySelector("browser.webextension-popup-browser"); and click on an extension button (e.g. uBlock Origin's button).

Comment 6

[Rob Wu [:robwu]]

Attachment: Bug 1949092 - Fix canOpenModalPicker for nested browsers + tests

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7f1aa02c220e
Fix canOpenModalPicker for nested browsers + tests r=edgar

Comment 8

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/7f1aa02c220e

Comment 9

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

The patch landed in nightly and beta is affected.
:robwu, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox136 to wontfix.

For more information, please visit BugBot documentation.

Comment 10

[Rob Wu [:robwu]]

Attachment: Bug 1949092 - Fix canOpenModalPicker for nested browsers + tests

Original Revision: https://phabricator.services.mozilla.com/D238843

Comment 11

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Fixes recent regression that has not reached release yet; File pickers and color pickers cannot be used from extension settings page and sidebars
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: See comment 0 of bug report
• Risk associated with taking this patch: Low
• Explanation of risk level: Issue well understood, fix is targeted in specific area where the logic was flawed before; includes unit tests for all relevant cases
• String changes made/needed: No
• Is Android affected?: no

Comment 12

[Rob Wu [:robwu]]

Attachment: Bug 1949092 - Fix canOpenModalPicker for nested browsers + tests

Original Revision: https://phabricator.services.mozilla.com/D238843

Comment 13

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/b7fb87f37939

Comment 14

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly (137.0a1/20250224170755) and Beta (136.0b10/20250223143918 from https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=55180bee8d857d8bd454040efe47889ccd8fe93e) under Windows 10 and Ubuntu 24.04 LTS.

As per the STR from Comment 0, clicking the “Browse…” button on the attached extension options page will display a file chooser dialog, confirming the fix.

Moreover, running the snippets from Comment 3 and Comment 5 as specified, will now return bc.canOpenModalPicker = true in all three cases mentioned in the comments, further confirming the fix.