Fix several corner case issues of scrollbar paint invalidation

Fix several corner case issues of scrollbar paint invalidation

- Invalidate composited scrollbars also during paint invalidation to
  avoid unnecessary invalidation on intermediate changes;

- Invalidate also on the containing box for moved/resized composited
  non-overlay scrollbars. This ensures the expanded/shrunk areas of the
  box because of scrollbar existence/width change are invalidated. This
  is the root cause of bug 535161.

- Avoid unnecessary invalidations on overlay scrollbar changes.

BUG=535161, 560418
Committed: https://crrev.com/48e402acbebf2717b8e79b89dba5310d31bf95da
Cr-Commit-Position: refs/heads/master@{#363998}

[Xianzhu, 2015-12-03 18:23:44]

Description was changed from

==========
Invalidate

BUG=560418
==========

to

==========
Fix several corner case issues of scrollbar paint invalidation

- Invalidate composited scrollbars also during paint invalidation to
  avoid unnecessary invalidation on intermediate changes;

- Invalidate also on the containing box for moved/resized composited
  non-overlay scrollbars. This ensures the expanded/shrunk areas of the
  box because of scrollbar existence/width change are invalidated. This
  is the root cause of bug 535161.

- Avoid unnecessary invalidations on overlay scrollbar changes.

BUG=535161,560418
==========

[Xianzhu, 2015-12-03 18:24:25]

wangxianzhu@chromium.org changed reviewers:
+ chrishtr@chromium.org, skobes@chromium.org

[chrishtr, 2015-12-03 18:52:36]

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp
(right):

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp:339:
layoutObject->setPreviousPaintInvalidationRect(LayoutRect());
Add a new virtual method LayoutObject::clearPreviousPaintInvalidationRects() and
override in LayoutBox?

This would avoid the isBox() stuff, and make the intent of the code here and the
other place clearer.

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp
(right):

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:75:
void
PaintInvalidationCapableScrollableArea::invalidatePaintOfScrollControlsIfNeeded(const
PaintInvalidationState& paintInvalidationState, const LayoutBoxModelObject&
paintInvalidationContainer)
There looks to be a lot of repeating code in this method. Also, it's hard to
read. Would it help to factor out an invalidation object that is repeated for
horizontal and vertical scrollbars? It would store invalidation rects and have
the other business logic below.

Or maybe a template/helper method?

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.h
(right):

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.h:31:
// Should be called when the box is changing paint invalidation container.
"Should be called when the previous paint invalidation rects are no longer
valid"

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.h:39:
bool m_horizontalScrollbarPreviouslyWasOverlay;
Can't you just clear out m_verticalScrollbarPreviousPaintInvalidationRect and
m_horizontalScrollbarPreviousPaintInvalidationRect when changing overlay state
rather than this?

[Xianzhu, 2015-12-03 22:13:28]

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp
(right):

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/compositing/PaintLayerCompositor.cpp:339:
layoutObject->setPreviousPaintInvalidationRect(LayoutRect());
On 2015/12/03 18:52:36, chrishtr wrote:
> Add a new virtual method LayoutObject::clearPreviousPaintInvalidationRects()
and
> override in LayoutBox?
> 
> This would avoid the isBox() stuff, and make the intent of the code here and
the
> other place clearer.

Done.

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp
(right):

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:75:
void
PaintInvalidationCapableScrollableArea::invalidatePaintOfScrollControlsIfNeeded(const
PaintInvalidationState& paintInvalidationState, const LayoutBoxModelObject&
paintInvalidationContainer)
On 2015/12/03 18:52:36, chrishtr wrote:
> There looks to be a lot of repeating code in this method. Also, it's hard to
> read. Would it help to factor out an invalidation object that is repeated for
> horizontal and vertical scrollbars? It would store invalidation rects and have
> the other business logic below.
> 
> Or maybe a template/helper method?

Done.

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.h
(right):

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.h:31:
// Should be called when the box is changing paint invalidation container.
On 2015/12/03 18:52:36, chrishtr wrote:
> "Should be called when the previous paint invalidation rects are no longer
> valid"

Done.

https://codereview.chromium.org/1491193003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.h:39:
bool m_horizontalScrollbarPreviouslyWasOverlay;
On 2015/12/03 18:52:36, chrishtr wrote:
> Can't you just clear out m_verticalScrollbarPreviousPaintInvalidationRect and
> m_horizontalScrollbarPreviousPaintInvalidationRect when changing overlay state
> rather than this?

No. We need to support the combinations of composited/non-composted and
overlay/non-overlay. For a non-composited non-overlay scrollbar, we need to save
its actual previous paintInvalidationRect for its own paint invalidation, while
check if the scrollbar affects the containing box's padding box size (ignoring
previousPaintInvalidationRect if the scrollbar was previously overlay).

[chrishtr, 2015-12-04 00:20:01]

https://codereview.chromium.org/1491193003/diff/40001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp
(right):

https://codereview.chromium.org/1491193003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:75:
needsPaintInvalidation = false;
I find overriding a parameter's value a confusing coding pattern.

https://codereview.chromium.org/1491193003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:83:
LayoutSize newNonOverlaySize = isOverlay ? LayoutSize() :
newPaintInvalidationRect.size();
It's weird to set a "newNonOverlaySize" variable in cases when isOverlay is
true..

[Xianzhu, 2015-12-04 01:08:37]

https://codereview.chromium.org/1491193003/diff/40001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp
(right):

https://codereview.chromium.org/1491193003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:75:
needsPaintInvalidation = false;
On 2015/12/04 00:20:01, chrishtr wrote:
> I find overriding a parameter's value a confusing coding pattern.

Done (needsPaintInvalidationArg and needsPaintInvalidation).

https://codereview.chromium.org/1491193003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:83:
LayoutSize newNonOverlaySize = isOverlay ? LayoutSize() :
newPaintInvalidationRect.size();
On 2015/12/04 00:20:00, chrishtr wrote:
> It's weird to set a "newNonOverlaySize" variable in cases when isOverlay is
> true..

Changed to
if (!isOverlay)
  newNonOverlaySize = ...

You can also read this as: if is overlay, then nonOverlaySize is empty.

[chrishtr, 2015-12-04 01:28:18]

https://codereview.chromium.org/1491193003/diff/60001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp
(right):

https://codereview.chromium.org/1491193003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:86:
if (!isOverlay)
It still reads confusingly to me. Isn't the logic you want something like this:

if (previouslyWasOverlay || isOverlay) {
  paintInvalidationContainer.invalidateDisplayItemClientOnBacking(box,
PaintInvalidationScroll, nullptr);
}
if (newPaintInvalidationRect.size() != previousPaintInvalidationRect.size()) {
  paintInvalidationContainer.invalidateDisplayItemClientOnBacking(box,
PaintInvalidationScroll, nullptr);
}

?

[Xianzhu, 2015-12-04 02:35:14]

https://codereview.chromium.org/1491193003/diff/60001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp
(right):

https://codereview.chromium.org/1491193003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:86:
if (!isOverlay)
On 2015/12/04 01:28:18, chrishtr wrote:
> It still reads confusingly to me. Isn't the logic you want something like
this:
> 
> if (previouslyWasOverlay || isOverlay) {
>   paintInvalidationContainer.invalidateDisplayItemClientOnBacking(box,
> PaintInvalidationScroll, nullptr);
> }
> if (newPaintInvalidationRect.size() != previousPaintInvalidationRect.size()) {
>   paintInvalidationContainer.invalidateDisplayItemClientOnBacking(box,
> PaintInvalidationScroll, nullptr);
> }
> 
> ?

No.

I'm comparing the new space and previous space used by the scrollbar in the box.
Perhaps 'newNonOverlaySize' can have a better name. Will
'newScrollbarUsedSpaceInBox' look better? 

Overlay scrollbar doesn't take box space, so its size change doesn't affect
padding box size, so we compute the nonOverlaySize of overlay scrollbars as
empty.

[Xianzhu, 2015-12-08 18:56:54]

ping...

[chrishtr, 2015-12-08 21:17:10]

https://codereview.chromium.org/1491193003/diff/60001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp
(right):

https://codereview.chromium.org/1491193003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:86:
if (!isOverlay)
On 2015/12/04 at 02:35:14, Xianzhu wrote:
> On 2015/12/04 01:28:18, chrishtr wrote:
> > It still reads confusingly to me. Isn't the logic you want something like
this:
> > 
> > if (previouslyWasOverlay || isOverlay) {
> >   paintInvalidationContainer.invalidateDisplayItemClientOnBacking(box,
> > PaintInvalidationScroll, nullptr);
> > }
> > if (newPaintInvalidationRect.size() != previousPaintInvalidationRect.size())
{
> >   paintInvalidationContainer.invalidateDisplayItemClientOnBacking(box,
> > PaintInvalidationScroll, nullptr);
> > }
> > 
> > ?
> 
> No.
> 
> I'm comparing the new space and previous space used by the scrollbar in the
box. Perhaps 'newNonOverlaySize' can have a better name. Will
'newScrollbarUsedSpaceInBox' look better? 

Yes, I think so.

> 
> Overlay scrollbar doesn't take box space, so its size change doesn't affect
padding box size, so we compute the nonOverlaySize of overlay scrollbars as
empty.

[Xianzhu, 2015-12-08 22:22:00]

https://codereview.chromium.org/1491193003/diff/60001/third_party/WebKit/Sour...
File
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp
(right):

https://codereview.chromium.org/1491193003/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/paint/PaintInvalidationCapableScrollableArea.cpp:86:
if (!isOverlay)
On 2015/12/08 21:17:10, chrishtr wrote:
> On 2015/12/04 at 02:35:14, Xianzhu wrote:
> > On 2015/12/04 01:28:18, chrishtr wrote:
> > > It still reads confusingly to me. Isn't the logic you want something like
> this:
> > > 
> > > if (previouslyWasOverlay || isOverlay) {
> > >   paintInvalidationContainer.invalidateDisplayItemClientOnBacking(box,
> > > PaintInvalidationScroll, nullptr);
> > > }
> > > if (newPaintInvalidationRect.size() !=
previousPaintInvalidationRect.size())
> {
> > >   paintInvalidationContainer.invalidateDisplayItemClientOnBacking(box,
> > > PaintInvalidationScroll, nullptr);
> > > }
> > > 
> > > ?
> > 
> > No.
> > 
> > I'm comparing the new space and previous space used by the scrollbar in the
> box. Perhaps 'newNonOverlaySize' can have a better name. Will
> 'newScrollbarUsedSpaceInBox' look better? 
> 
> Yes, I think so.
> 
> > 
> > Overlay scrollbar doesn't take box space, so its size change doesn't affect
> padding box size, so we compute the nonOverlaySize of overlay scrollbars as
> empty.
> 

Done.

[chrishtr, 2015-12-08 22:25:18]

The CQ bit was checked by chrishtr@chromium.org

[chrishtr, 2015-12-08 22:25:19]

lgtm

[commit-bot: I haz the power, 2015-12-08 22:27:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1491193003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1491193003/80001

[commit-bot: I haz the power, 2015-12-08 23:53:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-12-08 23:53:30]

Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)

[Xianzhu, 2015-12-08 23:58:48]

The CQ bit was checked by wangxianzhu@chromium.org

[commit-bot: I haz the power, 2015-12-08 23:59:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1491193003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1491193003/80001

[commit-bot: I haz the power, 2015-12-09 00:43:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-12-09 00:43:20]

Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Xianzhu, 2015-12-09 01:53:33]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2015-12-09 01:53:34]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org
Link to the patchset: https://codereview.chromium.org/1491193003/#ps100001
(title: "Rebaselines")

[commit-bot: I haz the power, 2015-12-09 01:58:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1491193003/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1491193003/100001

[commit-bot: I haz the power, 2015-12-09 04:23:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-12-09 04:23:19]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Xianzhu, 2015-12-09 05:26:10]

The CQ bit was checked by wangxianzhu@chromium.org

[Xianzhu, 2015-12-09 05:26:11]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org
Link to the patchset: https://codereview.chromium.org/1491193003/#ps120001
(title: " ")

[commit-bot: I haz the power, 2015-12-09 05:26:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1491193003/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1491193003/120001

[commit-bot: I haz the power, 2015-12-09 07:05:19]

Description was changed from

==========
Fix several corner case issues of scrollbar paint invalidation

- Invalidate composited scrollbars also during paint invalidation to
  avoid unnecessary invalidation on intermediate changes;

- Invalidate also on the containing box for moved/resized composited
  non-overlay scrollbars. This ensures the expanded/shrunk areas of the
  box because of scrollbar existence/width change are invalidated. This
  is the root cause of bug 535161.

- Avoid unnecessary invalidations on overlay scrollbar changes.

BUG=535161,560418
==========

to

==========
Fix several corner case issues of scrollbar paint invalidation

- Invalidate composited scrollbars also during paint invalidation to
  avoid unnecessary invalidation on intermediate changes;

- Invalidate also on the containing box for moved/resized composited
  non-overlay scrollbars. This ensures the expanded/shrunk areas of the
  box because of scrollbar existence/width change are invalidated. This
  is the root cause of bug 535161.

- Avoid unnecessary invalidations on overlay scrollbar changes.

BUG=535161,560418
==========

[commit-bot: I haz the power, 2015-12-09 07:05:19]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2015-12-09 07:06:18]

Description was changed from

==========
Fix several corner case issues of scrollbar paint invalidation

- Invalidate composited scrollbars also during paint invalidation to
  avoid unnecessary invalidation on intermediate changes;

- Invalidate also on the containing box for moved/resized composited
  non-overlay scrollbars. This ensures the expanded/shrunk areas of the
  box because of scrollbar existence/width change are invalidated. This
  is the root cause of bug 535161.

- Avoid unnecessary invalidations on overlay scrollbar changes.

BUG=535161,560418
==========

to

==========
Fix several corner case issues of scrollbar paint invalidation

- Invalidate composited scrollbars also during paint invalidation to
  avoid unnecessary invalidation on intermediate changes;

- Invalidate also on the containing box for moved/resized composited
  non-overlay scrollbars. This ensures the expanded/shrunk areas of the
  box because of scrollbar existence/width change are invalidated. This
  is the root cause of bug 535161.

- Avoid unnecessary invalidations on overlay scrollbar changes.

BUG=535161,560418

Committed: https://crrev.com/48e402acbebf2717b8e79b89dba5310d31bf95da
Cr-Commit-Position: refs/heads/master@{#363998}
==========

[commit-bot: I haz the power, 2015-12-09 07:06:19]

Patchset 7 (id:??) landed as
https://crrev.com/48e402acbebf2717b8e79b89dba5310d31bf95da
Cr-Commit-Position: refs/heads/master@{#363998}

[dominicc (has gone to gerrit), 2015-12-09 07:32:54]

A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/1513573004/ by dominicc@chromium.org.

The reason for reverting is: I suspect this may have broken the Oilpan build:

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac%20Oilpan/b....

[ccameron, 2015-12-11 00:02:14]

On 2015/12/09 at 07:32:54, dominicc wrote:
> A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/1513573004/ by dominicc@chromium.org.
> 
> The reason for reverting is: I suspect this may have broken the Oilpan build:
> 
>
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac%20Oilpan/b....

This also broke the fade-in and fade-out effect for Mac scrollbars (bisected to
this patch).

[Xianzhu, 2015-12-11 00:47:40]

On 2015/12/11 00:02:14, ccameron wrote:
> On 2015/12/09 at 07:32:54, dominicc wrote:
> > A revert of this CL (patchset #7 id:120001) has been created in
> https://codereview.chromium.org/1513573004/ by mailto:dominicc@chromium.org.
> > 
> > The reason for reverting is: I suspect this may have broken the Oilpan
build:
> > 
> >
>
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac%20Oilpan/b....
> 
> This also broke the fade-in and fade-out effect for Mac scrollbars (bisected
to
> this patch).

Are there test and bug for the issue?

[Xianzhu, 2015-12-11 19:48:59]

On 2015/12/11 00:02:14, ccameron wrote:
> On 2015/12/09 at 07:32:54, dominicc wrote:
> > A revert of this CL (patchset #7 id:120001) has been created in
> https://codereview.chromium.org/1513573004/ by mailto:dominicc@chromium.org.
> > 
> > The reason for reverting is: I suspect this may have broken the Oilpan
build:
> > 
> >
>
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac%20Oilpan/b....
> 
> This also broke the fade-in and fade-out effect for Mac scrollbars (bisected
to
> this patch).

ccamaron@, are there test and bug for the issue?

[ccameron, 2015-12-11 19:59:58]

On 2015/12/11 at 19:48:59, wangxianzhu wrote:
> On 2015/12/11 00:02:14, ccameron wrote:
> > On 2015/12/09 at 07:32:54, dominicc wrote:
> > > A revert of this CL (patchset #7 id:120001) has been created in
> > https://codereview.chromium.org/1513573004/ by mailto:dominicc@chromium.org.
> > > 
> > > The reason for reverting is: I suspect this may have broken the Oilpan
> build:
> > > 
> > >
> >
>
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac%20Oilpan/b....
> > 
> > This also broke the fade-in and fade-out effect for Mac scrollbars (bisected
> to
> > this patch).
> 
> ccamaron@, are there test and bug for the issue?

I didn't file a bug, because I already saw that this patch was reverted. Since
no test failed, there is not a test that hits exactly how it failed.

I suspect that the issue is that Scrollbar::setNeedsPaintInvalidation had no
effect.

[Xianzhu, 2015-12-11 20:05:16]

On 2015/12/11 19:59:58, ccameron wrote:
> On 2015/12/11 at 19:48:59, wangxianzhu wrote:
> > On 2015/12/11 00:02:14, ccameron wrote:
> > > On 2015/12/09 at 07:32:54, dominicc wrote:
> > > > A revert of this CL (patchset #7 id:120001) has been created in
> > > https://codereview.chromium.org/1513573004/ by
mailto:dominicc@chromium.org.
> > > > 
> > > > The reason for reverting is: I suspect this may have broken the Oilpan
> > build:
> > > > 
> > > >
> > >
> >
>
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac%20Oilpan/b....
> > > 
> > > This also broke the fade-in and fade-out effect for Mac scrollbars
(bisected
> > to
> > > this patch).
> > 
> > ccamaron@, are there test and bug for the issue?
> 
> I didn't file a bug, because I already saw that this patch was reverted. Since
> no test failed, there is not a test that hits exactly how it failed.
> 
> I suspect that the issue is that Scrollbar::setNeedsPaintInvalidation had no
> effect.

The revert was reverted just after the revert, so we have the bug in ToT.