1762018 - nightly black on black in search box on DDG

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[[e-mail]]

Attachment: nightly_black_on_black_in_search_box.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Used duckduckgo search engine or youtube.com search box with latest nightly build.

Actual results:

The search box now has black on black text when typing.

Expected results:

The search box should have had white on black text when typing.

Comment 1

[[e-mail]]

I tried running mozregression on the issue, but could not reproduce it. This only started happening in the last few days. Sunday, 20220327? It was not present last week, everything was working correctly. I'll see if I can change the test configuration to something that will reproduce the issue so I can find the culprit.

Comment 2

[[e-mail]]

This is the culprit:
17:15.11 INFO: No more integration revisions, bisection finished.
17:15.11 INFO: Last good revision: 94f858bf3452c1b6ed988b84d172d7e2412b9d5f
17:15.12 INFO: First bad revision: 4d1ab24c2912de564c9688c20290c3573cd07974
17:15.12 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=94f858bf3452c1b6ed988b84d172d7e2412b9d5f&tochange=4d1ab24c2912de564c9688c20290c3573cd07974

To get mozregression to work, I had to go into settings, then manage colors, I reset all the colors for dark theme and to suit my eyes, I then selected to apply them always. That is the configuration I use locally, so it makes sense that it would also fail when applied to the mozregression downloads.

Comment 3

[[e-mail]]

Attachment: nightly_showing_settings_page_with_custom_colors_selected_always.png

These are the settings that I had for colors to get the regression to trigger. The actual setting is now called manage colors, but has the same settings.

Comment 4

[[e-mail]]

I used youtube.com, the search box at the top, as it was easier than duckduckgo, to validate error or not.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Search' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 6

[Mark Banner (:standard8)]

Thank you for filing and finding the regression range.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

What colors did you get pre-regression? Presumably a white-ish background?

(Can check in a bit but if you can answer before I get to it that'd be great)

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1666059

Comment 9

[[e-mail]]

@7 Yes, the default appears to be black on white for the search box when it is working.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1762018 - Derive a color scheme when forcing preference colors. r=morgan

This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.

In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).

That should make sure that text from system colors is light and matches
the user expectations.

Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.

Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.

Not sure how to come up with a test for this right now without
hard-coding colors... Will try to come up with something tomorrow.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1762018 - Reftest. r=morgan

For some reason this test passes when ran standalone but fails when ran
as part of the whole directory. Needs more debugging.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5d97c7b1b9b5
Derive a color scheme when forcing preference colors. r=morgan

Comment 13

[Cristian Tuns]

Backed out for causing mochitest failures in test_bug232227.html

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | dom/canvas/test/test_bug232227.html | Stand-in computed color: ActiveBorder is correct. - got "rgb(250, 250, 250)", expected "rgb(180, 180, 180)"

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/09b4766eb9a5
Derive a color scheme when forcing preference colors. r=morgan

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4d65383640b4
Reftest. r=morgan

Comment 16

[Iulian Moraru]

Backed out for causing reftest failures on no-system-colors-color-scheme.html.

Push with failures

Failure log
Reftest analyzer link

Backout link

''' INFO '''

In the test image, the letters from the second row are grey and they should have been white.

''' INFO '''

Comment 17

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/09b4766eb9a5

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Hi Marco, is there something wrong with mach try auto and reftests? How can a new added reftest not run when push via mach try auto? https://treeherder.mozilla.org/jobs?repo=try&revision=2b1c15caea76837ed7ca033565c89553979d3795

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5c8ff314932f
Reftest. r=morgan

Comment 20

[Marco Castelluccio [:marco]]

The layout/reftests/high-contrast/reftest.list group was selected with 99% confidence, but unfortunately because of bug 1608836 the scheduler in m-c is not using reftest group selections but reftest task selections (which are far less precise).
Anyway, for modified tests, even when not selected, they are at least run by test-verify (in your push the group was run, for example, in test-linux1804-64-qr/debug-test-verify-gpu-fis-e10s).

Comment 21

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/5c8ff314932f

Comment 22

[[e-mail]]

Beginning with yesterday's nightly, things are working again. And working better than they originally did! Text is now white / light grey on dark grey / black background, instead of the original black on white. And the settings page, that used to be black text on white is now also white / light grey on dark grey.

Thank you!

Comment 23

[Emilio Cobos Álvarez (:emilio)]

Sweet, thanks for confirming!