User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36

Steps to reproduce:

• Install Firefox from Flathub on Debian testing
• open Youtube Music
• run playerctl metadata
• try to open the mpris:artUrl image outside Flatpak's Firefox

Actual results:

$ playerctl metadata 
firefox mpris:trackid             '/org/mpris/MediaPlayer2/firefox'
firefox xesam:title               Higher
firefox xesam:album               
firefox xesam:artist              Clean Bandit - Topic
firefox mpris:artUrl              file:///home/luiz/.mozilla/firefox/firefox-mpris/2_3.png

$ open file:///home/luiz/.mozilla/firefox/firefox-mpris/2_3.png
gio: file:///home/luiz/.mozilla/firefox/firefox-mpris/2_3.png: Error when getting information for file “/home/luiz/.mozilla/firefox/firefox-mpris/2_3.png”: No such file or directory

Expected results:

As explained by JasonLG1979 on his answer to the Issue I opened for gnome-shell-extension-mpris-indicator-button on Github, the correct url should point to Flatpak's Firefox folder (~/.var/app/org.mozilla.firefox/.mozilla/firefox/firefox-mpris/) resulting in:

firefox mpris:artUrl              file:///home/luiz/.var/app/org.mozilla.firefox/.mozilla/firefox/firefox-mpris/2_3.png

which I can open as expected while the song is playing.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

We need to correct the mLocalImageFolder here if FF is packed in Flatpak (is there a way to distinguish from Flatpak and non-Flatpak?), or we need to find another place that is common between Flatpak and non-Flatpak one to store the image, like /tmp. But we can run into a security/privacy issue if we'd like to store the image in a folder that is outside of FF's control. Not sure what is the better way. Leave the NI for now.

(In reply to C.M.Chang[:chunmin] from comment #2)

We need to correct the mLocalImageFolder here if FF is packed in Flatpak (is there a way to distinguish from Flatpak and non-Flatpak?), or we need to find another place that is common between Flatpak and non-Flatpak one to store the image, like /tmp. But we can run into a security/privacy issue if we'd like to store the image in a folder that is outside of FF's control. Not sure what is the better way. Leave the NI for now.

There's a way to detect if the firefox is run in flatpak like: https://searchfox.org/mozilla-central/source/widget/gtk/nsFilePicker.cpp#169

playerctl returns:
file:///home/jhorak/.mozilla/firefox/firefox-mpris/2_1.png
while in reality it is located (from the :
file:///home/jhorak/.var/app/org.mozilla.firefox/.mozilla/firefox/firefox-mpris/2_3.png

We could alter the path to insert .var/app/org.mozilla.firefox. But I'm unsure from where to get the right strings.
Which folders are shared between the container and host system is currently specified in flatpak manifest:
https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/runme.sh#149
which is basically only the download folder (this does not help).

(In reply to Jan Horak [:jhorak] from comment #3)

(In reply to C.M.Chang[:chunmin] from comment #2)

We need to correct the mLocalImageFolder here if FF is packed in Flatpak (is there a way to distinguish from Flatpak and non-Flatpak?), or we need to find another place that is common between Flatpak and non-Flatpak one to store the image, like /tmp. But we can run into a security/privacy issue if we'd like to store the image in a folder that is outside of FF's control. Not sure what is the better way. Leave the NI for now.

There's a way to detect if the firefox is run in flatpak like: https://searchfox.org/mozilla-central/source/widget/gtk/nsFilePicker.cpp#169

Hi Jan Horak, thanks for providing this information. It seems the line on the link is not related to Flatpak anymore. Would you mind pointing the line again?

playerctl returns:
file:///home/jhorak/.mozilla/firefox/firefox-mpris/2_1.png
while in reality it is located (from the :
file:///home/jhorak/.var/app/org.mozilla.firefox/.mozilla/firefox/firefox-mpris/2_3.png

We could alter the path to insert .var/app/org.mozilla.firefox. But I'm unsure from where to get the right strings.
Which folders are shared between the container and host system is currently specified in flatpak manifest:
https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/runme.sh#149
which is basically only the download folder (this does not help).

I am not sure if I understand this, or the pointed line has been changed. Do you mean it's better to add the directory storing the image MPRIS needs to this manifest? Is there a permission control here?

BTW, do you know how to build a flatpak version of FF?

The XDG_DATA_HOME env variable in the flatpak runtime points to the
/home/$USER/.var/app/org.mozilla.firefox/data directory. The same path
is also avalable in the host system, so if we put the art png there
then the dbus advertised path for the artUrl will be valid also for the host.

So this patch is fine (with the suggested fixes), but should we consider just changing the UAppData folder to point to XDG_DATA_HOME under flatpak? That seems it would fix other instances of this:

• https://searchfox.org/mozilla-central/search?q=UAppData%22&path=&case=false&regexp=false
• https://searchfox.org/mozilla-central/search?q=XRE_USER_APP_DATA_DIR&path=&case=false&regexp=false

It doesn't seem we use it for much else other than telemetry pings and crash reports, which maybe don't need access outside of the flatpak sandbox, but it might be a better long-term fix?

https://hg.mozilla.org/mozilla-central/rev/8664957be2fb