Bug 241231 - Regression(r294902) Web Inspector highlight gets stuck when hovering over items.
Summary: Regression(r294902) Web Inspector highlight gets stuck when hovering over items.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: zalan
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-06-02 10:49 PDT by zalan
Modified: 2022-06-02 18:20 PDT (History)
9 users (show)

See Also:


Attachments
Patch (4.50 KB, patch)
2022-06-02 11:16 PDT, zalan
no flags Details | Formatted Diff | Diff
Patch (3.96 KB, patch)
2022-06-02 12:00 PDT, zalan
ews-feeder: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description zalan 2022-06-02 10:49:11 PDT
<rdar://94257879>
Comment 1 zalan 2022-06-02 11:16:19 PDT
Created attachment 459967 [details]
Patch
Comment 2 Simon Fraser (smfr) 2022-06-02 11:20:35 PDT
Comment on attachment 459967 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=459967&action=review

> COMMIT_MESSAGE:14
> +This problem could be addressed in a few different ways including
> +- RenderLayer d'tor should always issue repaint when the "full repaint" flag is set (we may not be able to resolve the coordinates in d'tor)
> +- call force repaint on the renderer and ignore the repaint optimization (hard to tell when to use forced repaint)
> +- make sure repaint is actually issued before destroying the layer (local change. We may make the same mistake again)

This level of detail might be better in the bug, rather than the commit message.

> Source/WebCore/rendering/updating/RenderTreeBuilder.cpp:-957
> -        // We only repaint |child| if we have a RenderLayer as its visual overflow may not be tracked by its parent.

I guess this comment was stale? I see no layer checks here.
Comment 3 zalan 2022-06-02 11:58:50 PDT
Staring from r294902, when the RenderLayer says "I am scheduled for a full repaint", any subsequent repaint call on the associated renderer returns early (no repaint) as we are certain that a full repaint is going to be issued still within the current "rendering update" frame as part of the post-layout tasks.
Except this one case when soon after marking the RenderLayer dirty with the "needs full repaint" flag, we destroy both the layer and the associated renderer. In such cases the layer has no chance to issue the repaint.

This problem could be addressed in a few different ways including
1. RenderLayer d'tor should always issue repaint when the "full repaint" flag is set (we may not be able to resolve the coordinates in d'tor)
2. call force repaint on the renderer and ignore the repaint optimization (hard to tell when to use forced repaint)
3. make sure repaint is actually issued before destroying the layer (local change. We may make the same mistake again)

Since this bug is very specific to the destroying/detaching flow, I think it's ok to go with #3.
Comment 4 zalan 2022-06-02 12:00:13 PDT
Created attachment 459970 [details]
Patch
Comment 5 zalan 2022-06-02 12:00:49 PDT
> > Source/WebCore/rendering/updating/RenderTreeBuilder.cpp:-957
> > -        // We only repaint |child| if we have a RenderLayer as its visual overflow may not be tracked by its parent.
> 
> I guess this comment was stale? I see no layer checks here.
Yeah, I noticed it was stale and removed it.
Comment 6 EWS 2022-06-02 17:08:09 PDT
Committed r295155 (251243@main): <https://commits.webkit.org/251243@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 459970 [details].