Bug 241231 – Regression(r294902) Web Inspector highlight gets stuck when hovering over items.

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[zalan]

<rdar://94257879>

[zalan]

Created attachment 459967 [details]
Patch

[Simon Fraser (smfr)]

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.

[zalan]

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.

[zalan]

Created attachment 459970 [details]
Patch

[zalan]

> > 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.

[EWS]

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].