windy.com - colors missing from map layers
Categories
(Core :: Graphics: Color Management, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox75 | --- | unaffected |
firefox76 | --- | unaffected |
firefox77 | + | verified |
firefox78 | --- | verified |
People
(Reporter: miketaylr, Assigned: aosmond)
References
(Regressed 1 open bug, Regression, )
Details
(Keywords: regression)
Attachments
(5 files)
(Sorry for the poor title, I don't know how to describe this)
Originally reported @ https://github.com/webcompat/web-bugs/issues/51892
STR:
- load windy.com
Expected: You see a colorful map image with greens, yellows, reds, etc
Actual: None of that, just a blue and gray rain layer.
This gets SUPER obvious if you click on the temperature control on the top right.
In the console:
WebGL warning: texSubImage: Texture has not been initialized prior to a partial upload, forcing the browser to clear it. This may be slow. gl-particles.js:2:10223
WebGL warning: texSubImage: Tex image TEXTURE_2D level 0 is incurring lazy initialization.
11:04.45 INFO: Narrowed integration regression window from [ad3f58c9, 5f2454ac] (3 builds) to [ad3f58c9, 6392325e] (2 builds) (~1 steps left)
11:04.45 INFO: No more integration revisions, bisection finished.
11:04.45 INFO: Last good revision: ad3f58c996e59bc5ca0a0e6aac61c8f6a7e51096
11:04.45 INFO: First bad revision: 6392325ec39e5cb10edd4aaaa4afb7a9f061b0b2
11:04.45 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ad3f58c996e59bc5ca0a0e6aac61c8f6a7e51096&tochange=6392325ec39e5cb10edd4aaaa4afb7a9f061b0b2
Reporter | ||
Comment 1•5 years ago
|
||
[Tracking Requested - why for this release]: It's unclear how this change affects other sites, it breaks this one pretty much.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Can't reproduce on linux or windows, so might be mac specific.
@Mike: would you also be able to add your about:support information
Reporter | ||
Comment 3•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Comment 4•5 years ago
|
||
Also yeah, I can't reproduce on Windows either (on a VM)
Comment 5•5 years ago
|
||
I can reproduce on mac
Comment 6•5 years ago
|
||
I confirmed that setting gfx.color_management.mode=2 fixes the problem
Assignee | ||
Comment 7•5 years ago
|
||
I can reproduce on Linux if I force the browser to use the same color profile as the user.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 8•5 years ago
|
||
It appears the problem is related to color managing untagged JPEG images:
Assignee | ||
Comment 9•5 years ago
|
||
Adding nsLayoutUtils::SFE_NO_COLORSPACE_CONVERSION to CanvasRenderingContext2D::DrawImage's nsLayoutUtils::SurfaceFromElement call resolves the problem:
Before my pref change, it would have ignored any colorspace conversion because the JPEG has no ICC profile. Not sure what the actual fix should be yet.
Assignee | ||
Comment 10•5 years ago
|
||
As far as I can tell Chrome doesn't ask for any special behaviour for canvas. As such, it will enter this branch to try to load the ICC profile:
It doesn't have one so it calls Decoder()->ColorTransform():
source_to_target_color_transform_needs_update_ is false because we never added the ICC profile, so it doesn't actually fallback to assuming sRGB like we do. This explains why we see different behaviour (assuming I followed the lines correctly ;)).
Assignee | ||
Comment 11•5 years ago
|
||
Okay, I'll update the decoders to not assume sRGB if there is no reasonable colorspace indication to match Chrome's behaviour.
Comment 12•5 years ago
|
||
Andrew, will this 77 regression get fixed before the merge next Monday or should we expect an uplift in beta maybe? Thanks
Assignee | ||
Comment 13•5 years ago
|
||
I wrote the patch, but needed to fix some gtest related failures. Should be in before the merge but if not, it will be very upliftable/small change.
Assignee | ||
Comment 14•5 years ago
|
||
It appears some websites assume we will not color manage untagged images
and encode metadata in the image's surface data. Chrome matches this
behaviour. We should probably do the same for webcompat.
Comment 15•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Comment 16•5 years ago
|
||
bugherder |
Assignee | ||
Comment 17•5 years ago
|
||
Comment on attachment 9145590 [details]
Bug 1631615 - Don't color manage PNG/JPG/WebP if not tagged.
Beta/Release Uplift Approval Request
- User impact if declined: We have too aggressively color manage images which content authors did not intend to be color managed; if storing data like windy.com, it is hard to predict what would happen; it is also a webcompat issue with Chrome
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The patch is small well contained within imagelib and the individual decoders. We run a lot of tests through this path and the code coverage is high. We shipped for a very long time not color managing most untagged images.
- String changes made/needed:
Comment 18•5 years ago
|
||
Comment on attachment 9145590 [details]
Bug 1631615 - Don't color manage PNG/JPG/WebP if not tagged.
Looks low risk for early betas and has tests, approved for 77 beta 2, thanks.
Comment 19•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Updated•5 years ago
|
Comment 20•5 years ago
|
||
I reproduced the initial issue on Ubuntu 18.04 64bit using an old Nightly from 2020-04-20 where the color was completely off (full red map), but on Windows 10 64bit and MacOS 10.15.5 it reproduced a bit differently, the map was divided in different squares with different color tones (attached image).
On all platforms I can confirm that setting gfx.color_management.mode
on 2
fixes the problem on that old Nightly build and also on latest Nightly 78.0a1 from today and Firefox 77.0b3.
Comment 21•5 years ago
|
||
What I've noticed now (Windows 10 and Ubuntu 18.04 only) that there are a few lines flashing when zooming in/out, same lines I saw 1 comment above where the map was devided in different squares, should I log a new issue on this or should this issue be reopen here?
I did not notice the same behavior on Mac.
Updated•5 years ago
|
Assignee | ||
Comment 22•5 years ago
|
||
(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #21)
Created attachment 9146758 [details]
New issueWhat I've noticed now (Windows 10 and Ubuntu 18.04 only) that there are a few lines flashing when zooming in/out, same lines I saw 1 comment above where the map was devided in different squares, should I log a new issue on this or should this issue be reopen here?
I did not notice the same behavior on Mac.
Sounds like a different bug. Does it happen when color management is set to 2? If so, I would be confident it is unrelated. Please attach your about:support as well, since it will contain the color profile which may be useful for reproducing.
Comment 23•4 years ago
|
||
(In reply to Andrew Osmond [:aosmond] from comment #22)
(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #21)
Created attachment 9146758 [details]
New issueWhat I've noticed now (Windows 10 and Ubuntu 18.04 only) that there are a few lines flashing when zooming in/out, same lines I saw 1 comment above where the map was devided in different squares, should I log a new issue on this or should this issue be reopen here?
I did not notice the same behavior on Mac.Sounds like a different bug. Does it happen when color management is set to 2? If so, I would be confident it is unrelated. Please attach your about:support as well, since it will contain the color profile which may be useful for reproducing.
Yes, this does still happen with gfx.color_management.mode
set to 2
. I logged bug 1636856 on this issue and posted there the about:support content. I'll go ahead and close this one as verified fixed.
Comment 25•4 years ago
|
||
Is there any temporary workaround for this issue on windy.com while keeping gfx.color_management.mode=1?
Updated•4 years ago
|
Comment 26•2 years ago
|
||
(In reply to Mike Taylor [:miketaylr] from comment #1)
[Tracking Requested - why for this release]: It's unclear how this change affects other sites, it breaks this one pretty much.
I wanted to note that:
(1) this bug still exists on FF version 106.0.1 on Windows 11; and,
(2) this bug can also be seen on other websites, such as https://www.windfinder.com/#3/39.5000/-98.3500
Thanks
Comment 27•2 years ago
|
||
(In reply to Brett W. from comment #26)
(In reply to Mike Taylor [:miketaylr] from comment #1)
[Tracking Requested - why for this release]: It's unclear how this change affects other sites, it breaks this one pretty much.
I wanted to note that:
(1) this bug still exists on FF version 106.0.1 on Windows 11; and,
(2) this bug can also be seen on other websites, such as https://www.windfinder.com/#3/39.5000/-98.3500Thanks
Per my comment above, it seems like this should be reopened.
Comment 28•2 years ago
|
||
https://sf.atmo.ai seems to suffer from the same issue.
Comment 29•2 years ago
|
||
(In reply to Brett W. from comment #27)
Per my comment above, it seems like this should be reopened.
Unfortunately, no one can reopen bugs that are closed more than 1 year ago. Please create a clone of this bug.
Comment 30•2 years ago
|
||
(In reply to Masatoshi Kimura [:emk] from comment #29)
(In reply to Brett W. from comment #27)
Per my comment above, it seems like this should be reopened.
Unfortunately, no one can reopen bugs that are closed more than 1 year ago. Please create a clone of this bug.
Thanks for the heads up! The clone has been created at Bug 1797902.
Assignee | ||
Updated•9 months ago
|
Description
•