RESOLVED FIXED 237816
REGRESSION(r286955): Rendering Links during search: highlighting fails 
https://bugs.webkit.org/show_bug.cgi?id=237816
Summary REGRESSION(r286955): Rendering Links during search: highlighting fails
enometh
Reported 2022-03-12 21:11:32 PST
component: Webcore: product: webkitgtk-2.35.90 put the following html content in a file, say /dev/shm/1.html and open it with Minibrowser /dev/shm/1.html ``` <html><body> <p><a href="about:blank">foo bar</a></p> <p>foo bar var</p>r</body></html> ``` invoke the search facility with C-f and type "foo" in the search box: two instances of foo are highlighted but in first instance the line is rendered incorrectly: the line is rendered "foo___" where bar is invisible.
Attachments
Patch (5.60 KB, patch)
2022-03-15 04:57 PDT, Carlos Garcia Campos 		ews-feeder: commit-queue-
DetailsFormatted DiffDiff
Patch (6.50 KB, patch)
2022-03-17 04:51 PDT, Carlos Garcia Campos 		simon.fraser: review+
ews-feeder: commit-queue-
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Carlos Garcia Campos
Comment 1 2022-03-15 04:51:42 PDT
This is not GTK specific, but it's more noticeable because we use white color for the selection text foreground. This regressed in r286955, because in case of text with decorations, the foreground text is rendered in the same coalesced marked text loop than the decorations and StyledMarkedText::coalesceAdjacentWithEqualDecorations() doesn't take into account the text styles. So, when we start rendering from the beginning of the line, only one style marked text is generated and the whole line is painted with the selection style (white foreground), on white background it looks like the non selected text disappears. When we start selecting from the end of the line, a single styled marked text is generated, but the selected text is painted with the non-selected style, and it becomes white once we complete the line selection.
Carlos Garcia Campos
Comment 2 2022-03-15 04:57:58 PDT
Created attachment 454695 [details] Patch
Carlos Garcia Campos
Comment 3 2022-03-15 07:20:06 PDT
The test is actually passing in mac, but there are a few unrelated pixel differences in the image diff, maybe because of the transparent selection background. Any idea how to avoid it in mac?
Carlos Garcia Campos
Comment 4 2022-03-17 04:51:55 PDT
Created attachment 454959 [details] Patch
Radar WebKit Bug Importer
Comment 5 2022-03-18 17:28:06 PDT
<rdar://problem/90511939>
Carlos Garcia Campos
Comment 6 2022-03-21 01:35:39 PDT
Committed r291552 (248658@trunk): <https://commits.webkit.org/248658@trunk>
Darin Adler
Comment 7 2022-03-21 09:26:10 PDT
What did we do about the iOS failure?
Carlos Garcia Campos
Comment 8 2022-03-22 01:20:38 PDT
(In reply to Darin Adler from comment #7) > What did we do about the iOS failure? Oh, I'm sorry, I thought it was unrelated because I saw iOS failures with other patches too.
Darin Adler
Comment 9 2022-03-22 05:34:16 PDT
Yes, I think it probably is unrelated. For the health of the project I tend to try to get these fixed rather than start ignoring them across many different patches. So I typically don’t say “I can ignore this”, but rather “Who do I need to talk to to get this fixed?’
Note You need to log in before you can comment on or make changes to this bug.