1852990 - Firefox Flatpak (and Firefox snap on Ubuntu) cannot load unpacked temporary Add-ons from directory

Status: NEW

(WebExtensions :: Developer Tools, defect, P3)

Description

[easrng]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

• Install Firefox from a Flatpak
• Open about:debugging#/runtime/this-firefox
• Click "Load Temporary Add-on..."
• Choose a manifest.json file

Actual results:

The Add-on shows in the list of temporary Add-ons but the icon doesn't load and none of the code runs. This is because the Flatpak sandbox only gives access to the manifest.json file and not other files in the same folder.

Expected results:

Firefox should pick the files in such a way that the whole folder is loaded into the Flatpak sandbox so the Add-on's code can be run.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Add-ons Manager' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Flatpak Release (117.0.1/20230912013654) under Ubuntu 22.04 LTS. Could not find flatpaks for Nightly or Beta though to test them out as well.

As per Comment 0, the browser allows me to load the manifest.json and the add-on shows up in the list of temporary add-ons, however the icon does not load. Also trying to click on the extension button so as the add-on performs its functions will not do anything. Tested with https://addons.mozilla.org/en-US/firefox/addon/tomato-clock/.

Comment 3

[Rob Wu [:robwu]]

The "Load temporary add-on" option supports two modes of loading the extension, implemented at https://searchfox.org/mozilla-central/rev/431bcb0e88e49b92c6913c0916c7ad15e8a4875c/devtools/client/aboutdebugging/src/modules/extensions-helper.js#73-81:

• Load a zip/xpi file from disk
• Load the extension from the directory.
  • This requires the directory to contain a valid manifest.json file.

Flatpak should allow reading files when this approach is used.

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Martin
we were wondering if you may know if we would need to implement a new "Portal client" to give to Firefox a way to get access to the entire directory where the manifest.json file selected from the File picker is?

Based on a quick look it looks like org.freedesktop.portal.FileChooser may be the portal protocol that could be used also for getting temporary access to the directory where the extension to be installed temporarily is, and so I'm wondering if that is already implicitly used by the file picker already, and we should be making the FileChooser to select the directory instead of a single file to get access to the entire directory, or if that it is not yet being used and a new Portal client should be added on the Firefox side (e.g. like the PortalLocationProvider provides geolocation when it needs to be got through the xdg portal).

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

In the meantime, a workaround that should still work fine on a Flatpak Firefox build is to pack the entire extension directory into a single zip or xpi file and load that temporarily from about:debugging (instead of selecting a manifest.json from the unpacked extension).

Comment 6

[Martin Stránský [:stransky] (ni? me)]

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #4)

Hi Martin
we were wondering if you may know if we would need to implement a new "Portal client" to give to Firefox a way to get access to the entire directory where the manifest.json file selected from the File picker is?

Based on a quick look it looks like org.freedesktop.portal.FileChooser may be the portal protocol that could be used also for getting temporary access to the directory where the extension to be installed temporarily is, and so I'm wondering if that is already implicitly used by the file picker already, and we should be making the FileChooser to select the directory instead of a single file to get access to the entire directory, or if that it is not yet being used and a new Portal client should be added on the Firefox side (e.g. like the PortalLocationProvider provides geolocation when it needs to be got through the xdg portal).

Jan Horak is the best person here, he works on Firefox/Flatpak on Red Hat side.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

Bug 1852839 seems relevant work on the underlying internals, and so I'm linking it as a dependency in the meantime.

Comment 8

[Rob Wu [:robwu]]

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #7)

Bug 1852839 seems relevant work on the underlying internals, and so I'm linking it as a dependency in the meantime.

I'm not sure how that would help here. The file picker creator in about:debugging passes nsIFilePicker.modeOpen. While documented in IDL as "Load a file or directory", the existence of this bug shows that it does in fact not load a directory, but a file only. There is also an nsIFilePicker.modeGetFolder option, but if we select that, then the user would be unable to select an individual xpi/zip file.

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Rob Wu [:robwu] from comment #8)

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #7)

Bug 1852839 seems relevant work on the underlying internals, and so I'm linking it as a dependency in the meantime.

I'm not sure how that would help here. The file picker creator in about:debugging passes nsIFilePicker.modeOpen. While documented in IDL as "Load a file or directory", the existence of this bug shows that it does in fact not load a directory, but a file only. There is also an nsIFilePicker.modeGetFolder option, but if we select that, then the user would be unable to select an individual xpi/zip file.

I didn't say that was implicitly going to help without anything else being done, in comment 7 I purposely used the words "relevant work" .

In my opinion, we should keep an eye on that, and after that has been landed double-check if and how we could leverage that work and if we would need other changes too.

Also, in the meantime we may also have got some more perspective from Jan Horak, which may help us to get to more precise ideas about what we could be doing to cover the scenario.

Comment 10

[Jan Horak [:jhorak]]

Yes, this is another case for the Portal to open file and neighbouring files: https://github.com/flatpak/xdg-desktop-portal/issues/463# - but it seems to be stalled ATM.

Comment 11

[suleymanforai]

Still experiencing in the Flatpak from Flathub, Firefox Version 128.0.3 on Fedora Silverblue 40. It shows that the location of the extension is /run/user/1000/doc, not the directory I chose

Comment 12

[suleymanforai]

is my understanding correct that this is a Flatpak issue, not a Firefox Flatpak issue? Also, does zipping it up still work?

Comment 13

[Rob Wu [:robwu]]

This is both a Flatpak issue and a Firefox Flatpak issue.

The Flatpak issue is the lack of mechanism to select a file and its surrounding files (comment 10).

The Firefox issue is that it is affected by this and that it has not implemented a work-around. I can think of multiple ways, including:

• add a button that opens a directory picker instead.
• or without UI changes, when the selected file is not a zip/xpi, re-open the file picker and ask the user to select the directory. (If directory reading is not supported, ask the user to zip the file instead)

Patches are welcome.

Comment 15

[:gerard-majax]

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #4)

Hi Martin
we were wondering if you may know if we would need to implement a new "Portal client" to give to Firefox a way to get access to the entire directory where the manifest.json file selected from the File picker is?

Based on a quick look it looks like org.freedesktop.portal.FileChooser may be the portal protocol that could be used also for getting temporary access to the directory where the extension to be installed temporarily is, and so I'm wondering if that is already implicitly used by the file picker already, and we should be making the FileChooser to select the directory instead of a single file to get access to the entire directory, or if that it is not yet being used and a new Portal client should be added on the Firefox side (e.g. like the PortalLocationProvider provides geolocation when it needs to be got through the xdg portal).

Isn't it we are blocked on https://github.com/flatpak/xdg-desktop-portal/issues/463 ?

Comment 16

[Rob Wu [:robwu]]

(In reply to :gerard-majax from comment #15)

Isn't it we are blocked on https://github.com/flatpak/xdg-desktop-portal/issues/463 ?

Yes. Comment 10 also links there.
For increased visibility I'll link this URL in "See also".