Firefox Snap - Color management not working under Wayland
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: ladislav.horvath, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
Steps to reproduce:
1./ Installed ICC color profile in Ubuntu 24.04 under default Wayland session
2./ Openned default Firefox Snap browser and go to about:config from URL bar
3./ Specified path to my ICC color profile in "gfx.color_management.display_profile"
4./ Set "gfx.color_management.mode" to "1"
Actual results:
After restart of Firefox Snap, color are still the same, oversaturaded, unmanaged under Wayland session. But it's working as expected under X11 session.
Expected results:
Color management should be workind in Wayland session the same way how it's working under X11 or how it's working in standard Firefox debian package.
|
||
Comment 1•1 month 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.
|
||
Comment 2•23 days ago
|
||
Just to make sure, have you tried to reproduce outside of a snap package ? Could you also try using core24 base via sudo snap refresh --channel=latest/candidate firefox ?
|
Reporter | |
Comment 3•23 days ago
|
||
I can confirm its the same on the latest candidate. Under X11 are colors managed, under Wayland are not and.
Using debian package of Firefox, colors are managed under both X11 and Wayland sessions.
|
|
||
Comment 4•22 days ago
|
||
What is the path you used in gfx.color_management.display_profile ?
|
|
Reporter | |
Comment 5•22 days ago
|
||
I have tried path in my home profile and i have also tried to copy ICC profile system wide but it was the same
locally it was /home/usename/.local/share/icc/
system wide it was i think /usr/share/color/icc/colord/
|
|
||
Comment 6•22 days ago
|
||
(In reply to Ladislav Horvath from comment #5)
I have tried path in my home profile and i have also tried to copy ICC profile system wide but it was the same
locally it was /home/usename/.local/share/icc/
I can't remember out of the top of my head but this might be blocked by snapd
system wide it was i think /usr/share/color/icc/colord/
It's likely that the system wide path might be blocked by snapd
Ideally if you can install snappy-debug and run it while reproducing (I think just starting the browser after having changed the pref would be enough) this should show you the violation and help us verify further. Although it would be weird to work with X11 and not Wayland then.
|
|
Reporter | |
Comment 7•22 days ago
|
||
I have copied icc profile to my /home/username/ and from there can Firefox snap access it and use it, so colors are properly managed.
So you are right that propably those paths are blocked by snapd. Question is if this is a bug or only a configuration/packaging thing.
|
|
||
Updated•22 days ago
|
|
|
||
Comment 8•22 days ago
|
||
(In reply to Ladislav Horvath from comment #7)
I have copied icc profile to my /home/username/ and from there can Firefox snap access it and use it, so colors are properly managed.
So you are right that propably those paths are blocked by snapd. Question is if this is a bug or only a configuration/packaging thing.
Unfortunately there's a long tail of similar cases due to snapd limitations. Whether this should be fixed is not a question...
|
|
||
Comment 9•22 days ago
|
||
Nathan that's another use case where the addition of paths to snapd does not scale
|
|
Reporter | |
Comment 10•22 days ago
|
||
New experimental Ubuntu Security Center might solve this thing. I have turned it on and when i have downloaded some files in Firefox Snap, it asked for permission to read/write to my downloads folder. Sadly when launching Firefox snap, it does not ask for read access to /home/usename/.local/share/icc/ - maybe some detection issue.
https://snapcraft.io/install/desktop-security-center/ubuntu
This app is propably still in alpha/beta and i hope it will improve over time greatly. Currently is not possible to whitelist specific location, like for icc profile or user fontconfig files (also blocked), but later maybe users could add their own custom rules for locations..
|
|
Reporter | |
Comment 11•22 days ago
|
||
|
|
Reporter | |
Comment 12•22 days ago
|
||
After these findings i'm a bit ashamed. I should have done more tests before spamming bugzilla. This is obviously related to strict snap sandboxing and will affect all color managed apps, picture viewers/editors, video players etc. Imho there is nothing Mozilla can fix here..
|
|
||
Comment 13•20 days ago
|
||
(In reply to Ladislav Horvath from comment #11)
https://www.omgubuntu.co.uk/2024/09/ubuntus-new-security-center-readies-stable-release
Thanks, I dont remember from the previous issues but this might be a good solution to all those path we cannot realistically add manually
(In reply to Ladislav Horvath from comment #12)
After these findings i'm a bit ashamed. I should have done more tests before spamming bugzilla. This is obviously related to strict snap sandboxing and will affect all color managed apps, picture viewers/editors, video players etc. Imho there is nothing Mozilla can fix here..
Easy to say once we have found the root cause ... For now I'll close as WORKSFORME and this can serve as documentation.
|
||
Comment 14•16 days ago
|
||
It's surely a valid bug report, as you said Security Center is not yet ready and not all currently supported Ubuntu releases have it in the first place so this should be fixed at the snap level.
Dotfiles under the home directory are indeed out of bounds for the snaps. New interfaces can allow that, but they are a last resort measure, so first we could allow access to /usr/share/color/icc/colord. I'm not familiar with the concept of "color profiles" but is that something that each people would be opinionated about and so have one per user, or would allowance to the system-wide path already address the problem?
|
|
||
Comment 15•16 days ago
|
||
Also if you could kindly provide a clear-cut verification test, i.e. A instead of B
(A) Pick the background color of Firefox, it should be #DEADBE.
(B) Color management should be workind in Wayland session the same way how it's working under X11 or how it's working in standard Firefox debian package.
that would be much appreciated. But maybe it's not possible, it's OK.
Description
•