Bug 237816

Summary: REGRESSION(r286955): Rendering Links during search: highlighting fails
Product: WebKit Reporter: enometh
Component: CSSAssignee: Carlos Garcia Campos <cgarcia>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, cgarcia, changseok, darin, esprehn+autocc, ews-watchlist, glenn, kondapallykalyan, mcatanzaro, ntim, pdr, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=227445
Attachments:
Description Flags
Patch
ews-feeder: commit-queue-
Patch simon.fraser: review+, ews-feeder: commit-queue-

Description enometh 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.
Comment 1 Carlos Garcia Campos 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.
Comment 2 Carlos Garcia Campos 2022-03-15 04:57:58 PDT 
Created attachment 454695 [details]
Patch
Comment 3 Carlos Garcia Campos 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?
Comment 4 Carlos Garcia Campos 2022-03-17 04:51:55 PDT 
Created attachment 454959 [details]
Patch
Comment 5 Radar WebKit Bug Importer 2022-03-18 17:28:06 PDT 
<rdar://problem/90511939>
Comment 6 Carlos Garcia Campos 2022-03-21 01:35:39 PDT 
Committed r291552 (248658@trunk): <https://commits.webkit.org/248658@trunk>
Comment 7 Darin Adler 2022-03-21 09:26:10 PDT 
What did we do about the iOS failure?
Comment 8 Carlos Garcia Campos 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.
Comment 9 Darin Adler 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?’