STR: 1. View https://docs.google.com/presentation/d/1mxDAnusrzVFlQ5F12Q0CUxi7xV-LMreA9ha_4TRABJs/view Ignore the labels for the time being... Is the bottom image the same color as the top-left image, or the top-right image? EXPECTED RESULTS (based on other browsers; not 100% sure it's actually correct): Bottom image should match top-left. ACTUAL RESULTS: Bottom image matches top-right image. Latest Chrome and Safari gives "Expected results". Firefox gives "Actual results". Note: this is related to bug 1431518, but distinct from it (in terms of symptoms at least). - Bug 1431518 is about the fact that "Copy Image" produces a different image buffers in Firefox vs. Chrome. - This bug here is about the fact that Firefox & Chrome disagree about the rendering of that resulting pasted image (and specifically: while they agree on the rendering of the original image, they disagree about which pasted-result renders like the original image.) - The two bugs might have the same underlying cause, though.

Edge technically produces EXPECTED RESULTS due to the way I laid this out, but in an interesting way. The renderings on Win10 are as follows (where "dark", "medium", and "faint" are relative terms but mean the same thing on a given platform regardless of browser): Chrome: [medium][faint ] [medium] Firefox: [ dark ][medium] [medium] Edge: [ dark ][medium] [dark] In other words on my Win10 ThinkPad Laptop... - Firefox & Edge agree about the rendering of the top two (no-color-profile) images. (and Chrome is on its own, aside from webkit probably though I can't test that on Win10) - Firefox & Chrome agree about the rendering of the bottom (color-profile) image. (and Edge is on its own) - Edge & Chrome agree that the bottom image & top-left image should be the same color (though they disagree about what that color is) In googling about color management & color profiles, I found http://cameratico.com/tools/web-browser-color-management-test/ which shows two possible color-management issues: - Apparently Firefox doesn't support ICCv4 color profiles (which is maybe bug 1378603), per the purple/gray test there. - Apparently Firefox doesn't render untagged images & sRGB tagged images the same way. (Edge renders both with bright red & green; Chrome renders both with darker red & green; we render the untagged with bright red & green vs. sRGB tagged with dark red & green).

(In reply to Daniel Holbert [:dholbert] from comment #1) > In googling about color management & color profiles, I found > http://cameratico.com/tools/web-browser-color-management-test/ which shows > two possible color-management issues: > - Apparently Firefox doesn't support ICCv4 color profiles (which is maybe > bug 1378603), per the purple/gray test there. Ah, this is controlled by gfx.color_management.enablev4 (added in bug 674230, though never enabled) > - Apparently Firefox doesn't render untagged images & sRGB tagged images > the same way. (Edge renders both with bright red & green; Chrome renders > both with darker red & green; we render the untagged with bright red & green > vs. sRGB tagged with dark red & green). And this is controlled by gfx.color_management.mode (If I set that to 1, then the colors match as the page expects; documentation at http://kb.mozillazine.org/Gfx.color_management.enabled ) And: the latter is the relevant pref for this bug here. If I set "gfx.color_management.mode = 1" (away from its default of 2), then we match Chrome on the rendering here. I have faint memories around that pref and I think its default value (2) aims to strike a balance for legacy/webcompat reasons, though we might want to reevaluate that at some point now that Chrome is the dominant browser & they've apparently been able to make different webcompat decisions... (Also worth noting: neither of these prefs influences the behavior of "Copy image", i.e. neither affects bug 1431518. We produce the exact same image data on the clipboard, regardless of this pref.)

(In reply to Daniel Holbert [:dholbert] from comment #2) > If I set > "gfx.color_management.mode = 1" (away from its default of 2), then we match > Chrome on the rendering here. Given this ^^, this is effectively a dupe of bug 455077. > I have faint memories around that pref and I think its default value (2) > aims to strike a balance for legacy/webcompat reasons Nope, it was perf reasons, as discussed at https://bholley.wordpress.com/2008/09/12/so-many-colors/ . Anyway, hopefully we'll eventually sort this out in bug 455077 -- maybe the perf impact isn't so bad anymore.