1903195 - Find-in-page match text is drawn with poor contrast (from ::selection background) if you switch focus away and back

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase.
2. Ctrl+F to find-in-page
3. Type "link", and look very closely at the page rendering.
4. Switch tabs away and back (e.g. Ctrl+T to open a new tab, Ctrl+W to close that new tab)
5. Compare to the rendering from step 3.

ACTUAL RESULTS:
The find-in-page match looks quite different in step 5 vs. step 3. Most notably, the word "link" in the find-in-page match is unreadable at the end (cyan text over cyan background). But also, the rest of that link is drawn with a black background, indicating that the link is selected in step 5, when it was not in step 3.

EXPECTED RESULTS:
Consistent styling between step 5 and step 3. The page should look the way that I left it.

This bug sort of spans the ::selection, find-in-page, and CSS components; I'm starting it in DOM::selection, but it might want to move.

Comment 1

[Daniel Holbert [:dholbert]]

I filed this because I ran into it on Bugzilla, FWIW. I can reproduce it on this very bug page if I e.g. do find-in-page for "testcase" and then do Ctrl+G so that some in-view link with the word "testcase 1" is selected. When I switch tabs away and back, I end up seeing dark-turquoise-text-on-dark-pink-background which is a bit hard to read and I think never a state that we/Bugzilla intend to show.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug with attached testcase

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug reproducing on Bugzilla (with "highlight all" checked)

Comment 4

[Daniel Holbert [:dholbert]]

Chrome gives EXPECTED RESULTS; when I return to the tab, it looks the same as when I left it, in terms of find-in-page highlighting.

Comment 5

[Daniel Holbert [:dholbert]]

I'm testing with Firefox Nightly 129.0a1 (2024-06-17) on Ubuntu 22.04.

I don't think this is a regression, or not a recent one at least. I can reproduce it in Nightly 2022-01-01, for example (over 2 years old)

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The green-hilighted range is a normal selection range whose selection state is "attention" (nsISelectionController::SELECTION_ATTENTION). It's set by nsTypeAheadFind::FindItNow when it find the text. Then, the state is set to "disabled" when the document is inactivated. Finally, it's restored as "on" when the document becomes active. Therefore, the range is painted as a normal selected text which may be styled as hard to read.

So, it's not our bug that it's hard to read because the style specified as so. However, I don't know whether the "attention" state is not restored is intentional or a bug.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI: You can select link text with Alt. Then, you see same result.

Comment 8

[Daniel Holbert [:dholbert]]

Aha, thanks.

So looking at the real-world site on Bugzilla-with-dark-theme-applied (shown in my second screencast): it seems that the "bad" final state (dark-turquoise-text-on-dark-pink-background) is coming from the text being drawn with two selection backgrounds over the same exact range:
(1) pink (from being a find-in-page match)
(2) teal (from the "attention" selection that appears)

And the dark-turquoise text is actually just white text which has been tinted by the semitransparent teal overlay from (2).

I can get into this state without switching tabs by first doing find-in-page and ticking "Highlight All", and then clicking-and-dragging to select a range that happens to include a link with a find-in-page match inside of it. With those STR, our rendering seems ~fine and understandable.

However, I don't know whether the "attention" state is not restored is intentional or a bug.

Yeah, this part (find-in-page failing to restore the attention state in the same form that it was when we lost focus) seems like the piece here that is a bug.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Daniel Holbert [:dholbert] from comment #8)

Aha, thanks.

So looking at the real-world site on Bugzilla-with-dark-theme-applied (shown in my second screencast): it seems that the "bad" final state (dark-turquoise-text-on-dark-pink-background) is coming from the text being drawn with two selection backgrounds over the same exact range:
(1) pink (from being a find-in-page match)
(2) teal (from the "attention" selection that appears)

Ah, I see. As far as I've tested on Bugzilla, it's a painting issue in nsTextFrame. Normal selection is always painted as so when I select around hilighted words (with pink background). Currently, nsTextPaintStyle checks only the background of the text frame. However, actual background may be another type of selection range. This means that we need to consider background and text colors per grapheme cluster, but it's too complicated and needs to rewrite the selection painting...

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I guess the simplest solution is, stop painting other background colors and text colors under normal selection ranges.