So the test in question is this one (newlines added for readability): ``` pref(browser.display.use_system_colors,true) pref(browser.display.document_color_use,0) test-pref(layout.css.prefers-color-scheme.content-override,0) != about:blank about:blank ``` https://searchfox.org/mozilla-central/rev/81c95e56daabc6b6cd84b65349fc6163c490f957/layout/reftests/high-contrast/reftest.list#88 That reftest came from Bug 1739699, https://hg.mozilla.org/integration/autoland/rev/498dca8a1373 -- needinfo'ing emilio. In the failures that I've looked at here, both reftest snapshots are fully `black` (which is a failure since it's a not-equal test). From setting the test's prefs locally (on Linux), it looks like `black` is the right coloring for the testcase (that's how `about:blank` looks when I have with all 3 prefs set), whereas `white` is the right coloring for the reference case (that's how `about:blank` looks when I have just the first two prefs set). Based on the failure, I assume we've got a race condition of some sort here, where our reference-case's removal of `layout.css.prefers-color-scheme.content-override` hasn't taken effect in time for the reference case snapshot, given that: - the failure was intermittent until a change to refresh-rate made it perma-failing - the failure happens on debug too but to a much lower rate (i.e. we're "winning" the race there due to debug-related changes in timing) So this is probably a bug in handling the `layout.css.prefers-color-scheme.content-override` pref (it's not sufficiently synchronous/immediate, I guess). If we need an extremely short-term stopgap, we could probably mark this test as skipped on macOS opt builds. Longer-term we need to figure out why the race condition is failing and address it in the code and/or in a more-robust test. It's also conceivable that something is fiddly with the `about:blank` URLs here, causing the testcase-to-reference-case navigation to be considered as the same page rather than a navigation; I can't remember if the reftest harness navigates somewhere else in between. If that's part of the issue, we might be able to address that by adding `?test` and `?ref` as suffixes to the URL or sometihng.
Bug 1764585 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
So the test in question is this one (newlines added for readability): ``` pref(browser.display.use_system_colors,true) pref(browser.display.document_color_use,0) test-pref(layout.css.prefers-color-scheme.content-override,0) != about:blank about:blank ``` https://searchfox.org/mozilla-central/rev/81c95e56daabc6b6cd84b65349fc6163c490f957/layout/reftests/high-contrast/reftest.list#88 That reftest came from Bug 1739699, https://hg.mozilla.org/integration/autoland/rev/498dca8a1373 -- needinfo'ing emilio. In the failures that I've looked at here, both reftest snapshots are fully `black` (which is a failure since it's a not-equal test). From setting the test's prefs locally (on Linux), it looks like `black` is the right coloring for the testcase (that's how `about:blank` looks when I have all 3 prefs set), whereas `white` is the right coloring for the reference case (that's how `about:blank` looks when I have just the first two prefs set). Based on the failure, I assume we've got a race condition of some sort here, where our reference-case's removal of `layout.css.prefers-color-scheme.content-override` hasn't taken effect in time for the reference case snapshot, given that: - the failure was intermittent until a change to refresh-rate made it perma-failing - the failure happens on debug too but to a much lower rate (i.e. we're "winning" the race there due to debug-related changes in timing) So this is probably a bug in handling the `layout.css.prefers-color-scheme.content-override` pref (it's not sufficiently synchronous/immediate, I guess). If we need an extremely short-term stopgap, we could probably mark this test as skipped on macOS opt builds. Longer-term we need to figure out why the race condition is failing and address it in the code and/or in a more-robust test. It's also conceivable that something is fiddly with the `about:blank` URLs here, causing the testcase-to-reference-case navigation to be considered as the same page rather than a navigation; I can't remember if the reftest harness navigates somewhere else in between. If that's part of the issue, we might be able to address that by adding `?test` and `?ref` as suffixes to the URL or sometihng.