Flatpak incomplete mpris:artUrl
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox99 | --- | fixed |
People
(Reporter: luizhfsilva, Assigned: jhorak, NeedInfo)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
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.
Comment 1•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
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.
Assignee | ||
Comment 3•3 years ago
|
||
(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).
Comment 4•3 years ago
|
||
(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?
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
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.
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Comment 6•3 years ago
|
||
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®exp=false
- https://searchfox.org/mozilla-central/search?q=XRE_USER_APP_DATA_DIR&path=&case=false®exp=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?
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8664957be2fb Make the mpris:artUrl accessible outside of flatpak app; r=emilio
Comment 8•3 years ago
|
||
bugherder |
Description
•