Firefox snap Ubuntu 22.04.1 LTS handles /tmp reference incorrectly.
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: bill, Unassigned)
References
(Blocks 2 open bugs)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36
Steps to reproduce:
I have a script that runs Firefox periodically all day to pop up messages. The URL is file:///tmp/Message.html where the script writes the contents of that file as necessary. I discovered that any reference to the real /tmp get directed to /tmp/snap.firefox/tmp and then Firefox display a file not found. If I move MESSAGE.html to my home directory Firefox executes it just fine.
Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0
Actual results:
File not found error because Firefox is looking inside its /tmp/snap.firefox/tmp directory and not the systems /tmp where the file is actually available.
Expected results:
Use the system's /tmp directory.
|
||
Comment 1•2 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 correct in case you think the bot is wrong.
This also effects downloads, which silently get redirected from /tmp/ to this sub folder.
It can not be expected that the user picks to save in /tmp but files show up in a different folder.
|
||
Comment 5•2 years ago
|
||
(In reply to tc from comment #4)
It can not be expected that the user picks to save in /tmp but files show up in a different folder.
Please keep download specific issues where they are, there is enough of problems to deal with right now on that part. My answer was about the behavior that /tmp is being read from /tmp/snap.firefox/tmp
|
||
Comment 6•2 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #3)
I worry this is expected
Yes, this is by design with the snap confinement, where strictly-confined apps are not allowed to peek at other apps' tmp folder. I.e., there is no shared tmp folder.
Bill, for you specific use case, I would suggest writing that file somewhere under $HOME, where the firefox snap can see it. Given that you control that script, you can ensure the file is deleted afterwards.
|
|
||
Comment 7•2 years ago
|
||
So there is not much we can do there.
|
Reporter | |
Comment 8•2 years ago
|
||
I already resolved my issue by using my home directory, but that doesn't fix the problem of the app deciding to convert the user's request to some other location. The proper response would be to put up some security error message and not some bogus file not found.
|
||
Comment 9•2 years ago
|
||
I agree Bill, but Alexandre has already decided Mozilla are not going to bother having a good experience for Snap users.
|
||
Comment 10•2 years ago
|
||
(In reply to Tom Chiverton from comment #9)
I agree Bill, but Alexandre has already decided Mozilla are not going to bother having a good experience for Snap users.
If I understand correctly, that's just how Snap works.
Alternative:
Download the .tar.gz: https://www.mozilla.org/firefox/new/
Create your own .desktop file, example: bug 1751153 comment 19
|
|
||
Comment 11•2 years ago
|
||
(In reply to Darkspirit from comment #10)
(In reply to Tom Chiverton from comment #9)
I agree Bill, but Alexandre has already decided Mozilla are not going to bother having a good experience for Snap users.
If I understand correctly, that's just how Snap works.
Are Mozilla going to work with upstream xdg-XXX projects to improve Snap (e.g. add an API for "get writable locations that have the same path in the Snap as outside") ? Or just leave it with a broken experience ?
|
|
||
Comment 12•2 years ago
|
||
First, i have not decided anything, i asked people working on Snap and i was told this was by design and we cannot expect much. Second, when there are API limitations, yes, we are pushing to upstream as much as we can, and on several download issues things are stalling on their side and there is not much in my power expect being too pushy to the risk of being abusive or toxic, which nobody wants.
|
|
||
Comment 13•2 years ago
|
||
Maybe I misunderstand Bugzilla, but the bug was closed invalid, rather than tracking an upstream feature request or similar. This doesn't feel like Mozilla are trying to get upstream to provide the needed changes.
|
|
||
Comment 14•2 years ago
|
||
I asked upstream, they told it was by design. Feel free to push upstream for that, but we already have others issues much difficult to deal with.
|
|
||
Comment 15•2 years ago
|
||
Happy to. Where's the thread/bug ?
|
|
||
Comment 16•2 years ago
|
||
This was on Irc, so i dont think logs are kept. If you get traction on that, please add it to this bug, we can reopen if it becomes fixable.
|
|
||
Comment 17•2 years ago
|
||
Just look at the meta bug for Snap and see the amount of issues i reported or even fixed myself directly in upstream either ubuntu or xdg if you still are not convinced i am taking it seriously
Description
•