Reported at http://crbug.com/84384. The cause is in FrameSelection::recomputeCaretRect(). This method invalidates the rect in which the caret is supposed to be rendered, even if the caret never appears. We only need to invalidate the rect when the caret is certainly rendered.
Created attachment 95412 [details] Patch V0
(In reply to comment #1) > Created an attachment (id=95412) [details] > Patch V0 The test of this patch might pass the run-webkit-tests even the patch are not applied. I checked the test failed on Chromium (mac/linux) and Safari w/o the patch. I'd like to ask some advice to correct the test. Regards,
At this time, I recommend you not to use reftests. It's not ready on buildbots.
Comment on attachment 95412 [details] Patch V0 r- for now to clear up the queue.
Hi Morita-san, Thank you for review. (In reply to comment #3) > At this time, I recommend you not to use reftests. It's not ready on buildbots. I see. Then, I think this bug should be checked by a pixel test. How can I make -expected.png for each platform? This bug is platform-independent.
Created attachment 96201 [details] Patch V1
Comment on attachment 96201 [details] Patch V1 View in context: https://bugs.webkit.org/attachment.cgi?id=96201&action=review Code looks simple enough. I'd like to hear from experts. > LayoutTests/fast/repaint/text-shadow-selection.html:30 > + }, 100); unless there is special reasons, you shouldn't use setTimeout with non-zero wait time - it actually spend that time and make a test slow. In many case it can be replaced with layoutTestController.leapForward().
Comment on attachment 96201 [details] Patch V1 View in context: https://bugs.webkit.org/attachment.cgi?id=96201&action=review >> LayoutTests/fast/repaint/text-shadow-selection.html:30 >> + }, 100); > > unless there is special reasons, you shouldn't use setTimeout with non-zero wait time - it actually spend that time and make a test slow. > In many case it can be replaced with layoutTestController.leapForward(). I tried to use zero wait time out but I couldn't see the expected behavior in which the text shadow breaks up when I ran the test without the patch. I agree with your concern so I'd be grad if someone could give suggestions to revise the test.
Comment on attachment 96201 [details] Patch V1 View in context: https://bugs.webkit.org/attachment.cgi?id=96201&action=review > LayoutTests/fast/repaint/text-shadow-selection.html:13 > +.textshadow { > + text-shadow: 10px 0px red; > + font-family: sans-serif; > + font-size: 36pt; > + font-weight: bold; > +} > +::selection { > + background: #ccc; > + text-shadow: none; > +} There is no @font-face in this testcase, so is the bug title no longer accurate? > Source/WebCore/editing/FrameSelection.cpp:1218 > + view->repaintRectangleInViewAndCompositedLayers(oldAbsoluteCaretRepaintBounds, false); > view->repaintRectangleInViewAndCompositedLayers(m_absoluteCaretRepaintBounds, false); This change doesn't seem right. An extra invalidate via repaintRectangleInViewAndCompositedLayers() should not cause repaint failure, only extra work. By making this change, you're opening up the possibility that we'll leave stale images of the caret around.