User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

Videos have a red/yellow tint. No tint when testing the 2023-05-11 build. (both builds tested with a new profile)

(added screenshot of a tint on the left compared to no tint on the right)

Can you get a regresssion window using mozregression?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #1)

Can you get a regresssion window using mozregression?

I used that before posting to see when it broke. It's broken in the first build from 2023-05-12 that is tested after the build from 2023-05-11 is tested. I can run it again later to get the full details if necessary.

Yes please. Having the additional details would be very helpful.

Also, can you check if you see this on release? (113.0.1)

Ok, it was working on build 20230511213213 and was broken on the build with build_date: 2023-05-12 11:32:46.209000 (20230512094914 ? it's hard to figure out from the log which build is related to which test), it says the mozilla-central build is cb3f2eb3

Doesn't happen on 113.0.1

Updating that it seems to be related to bug 1832971 because setting gfx.color_management.native_srgb to true fixes it, though I don't think HDR is enabled in my system (at least, it's not something that I actively changed recently unless it was done by Windows Update or the like)

Likely regressed by bug 1832215 since setting native_srgb to true fixes this.

:jgilbert, since you are the author of the regressor, bug 1832215, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

(In reply to Jamie Nicol [:jnicol] from comment #7)

Likely regressed by bug 1832215 since setting native_srgb to true fixes this.

So let me get this straight:
In the past (112) this used to default to false > no issue
In version 113 it was somehow changed to true > issues reported with colour management (esp. wider gamut displays)
--> it was changed back to false (113.0.1 and further) and now > in beta/nightly versions 114/115 there are (HDR) video issues.

To me it then seems the flag "native_srgb" alone is not the cause of these reports but interacts with other developments around HDR video handling in 114 and onwards.
If the default value was flipped to true, because the HDR video does not render properly otherwise, then the changes to that video component seem to be the regression to me. Not the reverting of the flag to it's original value.

Yes, indeed. Clearly there is more to it than just this pref. However, the recent pref reversion is what caused this specific issue for the reporter of this bug. It's useful for us to track it in this manner to ensure that we don't miss any of the bugs and eventually resolve the issue for everybody.

Understood.

So the Mozregression trace back that is done here lands on the changeset related to the flipping back of this one default to fix bug 1832215.
Could you force the flag to false from that point and trace further back to find the earlier interacting change(s)?

This is a candidate diff: https://phabricator.services.mozilla.com/D161857 bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1799258
This was also mentioned as the regressor causing bug 1832215

See Bug 1833030,
FWIW,
Setting gfx.webrender.dcomp-video-overlay-win to false seems to fix Bug 1833030 on Nightly115.0a1 and 114.0b4 Windows10 without changing the other preferences.

webrender.dcomp-video-overlay seems to interfere with video color management.