Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

We still invalidate the scroll controls on ScrollableArea, which is used if the
scrollbars are painted into the ScrollableArea itself, rather than composited
layers.

The thumbNeedsRepaint property on Scrollbar is used to repaint a scrollbar thumb
that's actually changed appearance. This isn't actually needed when the thumb
simply changes scroll offset. Nor is it needed when the enabled/disabled state
changes since the compositor knows how to hide them itself. Thus, a composited
scrollbar now needs to repaint only when the hovered or pressed state changes
or if there's a geometry change.

BUG=669670
Committed: https://crrev.com/65f5be3dadd8a0a752effd7073a12f9ecdb1c472
Cr-Commit-Position: refs/heads/master@{#440450}

[bokan, 2016-12-21 01:16:51]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-21 01:17:35]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-21 01:23:13]

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

[commit-bot: I haz the power, 2016-12-21 01:23:13]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[bokan, 2016-12-21 13:53:39]

The CQ bit was checked by bokan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-21 13:53:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-21 16:13:20]

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

[commit-bot: I haz the power, 2016-12-21 16:13:20]

Dry run: This issue passed the CQ dry run.

[bokan, 2016-12-21 16:24:27]

Description was changed from

==========
Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

We still invalide the scroll controls on ScrollableArea, which is used if the
scrollbars are painted into the ScrollableArea itself, rather than composited
layers.

The thumbNeedsRepaint property on Scrollbar is used to repaint a scrollbar thumb
that's actually changed appearance. This isn't actually needed when the thumb
simply changes scroll offset. Nor is it needed when the enabled/disabled state
changes since the compositor knows how to hide them itself. Thus, a composited
scrollbar now needs to repaint only when the hovered or pressed state changes
or if there's a geometry change.

BUG=669670
==========

to

==========
Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

We still invalide the scroll controls on ScrollableArea, which is used if the
scrollbars are painted into the ScrollableArea itself, rather than composited
layers.

The thumbNeedsRepaint property on Scrollbar is used to repaint a scrollbar thumb
that's actually changed appearance. This isn't actually needed when the thumb
simply changes scroll offset. Nor is it needed when the enabled/disabled state
changes since the compositor knows how to hide them itself. Thus, a composited
scrollbar now needs to repaint only when the hovered or pressed state changes
or if there's a geometry change.

BUG=669670
==========

[bokan, 2016-12-21 16:24:28]

bokan@chromium.org changed reviewers:
+ skobes@chromium.org

[skobes, 2016-12-21 18:04:07]

lgtm w/ nit

https://codereview.chromium.org/2590163004/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/scroll/ScrollbarThemeOverlayTest.cpp
(right):

https://codereview.chromium.org/2590163004/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/scroll/ScrollbarThemeOverlayTest.cpp:79: //
invalidated as it's state is changed to hover.
it's -> its

[bokan, 2016-12-22 15:02:31]

bokan@chromium.org changed reviewers:
+ jbroman@chromium.org

[bokan, 2016-12-22 15:02:32]

+jbroman@ for OWNER

https://codereview.chromium.org/2590163004/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/scroll/ScrollbarThemeOverlayTest.cpp
(right):

https://codereview.chromium.org/2590163004/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/scroll/ScrollbarThemeOverlayTest.cpp:79: //
invalidated as it's state is changed to hover.
On 2016/12/21 18:04:07, skobes wrote:
> it's -> its

Done.

[bokan, 2016-12-22 15:02:32]

+jbroman@ for OWNER

[jbroman, 2016-12-22 15:19:10]

Description was changed from

==========
Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

We still invalide the scroll controls on ScrollableArea, which is used if the
scrollbars are painted into the ScrollableArea itself, rather than composited
layers.

The thumbNeedsRepaint property on Scrollbar is used to repaint a scrollbar thumb
that's actually changed appearance. This isn't actually needed when the thumb
simply changes scroll offset. Nor is it needed when the enabled/disabled state
changes since the compositor knows how to hide them itself. Thus, a composited
scrollbar now needs to repaint only when the hovered or pressed state changes
or if there's a geometry change.

BUG=669670
==========

to

==========
Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

We still invalidate the scroll controls on ScrollableArea, which is used if the
scrollbars are painted into the ScrollableArea itself, rather than composited
layers.

The thumbNeedsRepaint property on Scrollbar is used to repaint a scrollbar thumb
that's actually changed appearance. This isn't actually needed when the thumb
simply changes scroll offset. Nor is it needed when the enabled/disabled state
changes since the compositor knows how to hide them itself. Thus, a composited
scrollbar now needs to repaint only when the hovered or pressed state changes
or if there's a geometry change.

BUG=669670
==========

[jbroman, 2016-12-22 15:21:01]

lgtm with two comments

https://codereview.chromium.org/2590163004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/BUILD.gn (right):

https://codereview.chromium.org/2590163004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/BUILD.gn:1835: sources += [
"scroll/ScrollbarThemeOverlayTest.cpp" ]
If you leave this here, put these in one list:

sources += [
  "scroll/ScrollbarThemeAuraTest.cpp",
  "scroll/ScrollbarThemeOverlayTest.cpp",
]

But ScrollbarThemeOverlay seems to be built in !use_default_render_theme builds
too, so why is this not just in the main unit test file list?

https://codereview.chromium.org/2590163004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/scroll/ScrollbarTestSuite.h (right):

https://codereview.chromium.org/2590163004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/scroll/ScrollbarTestSuite.h:24: // Public to
allow using NiceMock.
Does protected not work? NiceMock<T> derives from T.

[bokan, 2016-12-22 16:10:55]

https://codereview.chromium.org/2590163004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/BUILD.gn (right):

https://codereview.chromium.org/2590163004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/BUILD.gn:1835: sources += [
"scroll/ScrollbarThemeOverlayTest.cpp" ]
On 2016/12/22 15:21:00, jbroman wrote:
> If you leave this here, put these in one list:
> 
> sources += [
>   "scroll/ScrollbarThemeAuraTest.cpp",
>   "scroll/ScrollbarThemeOverlayTest.cpp",
> ]
> 
> But ScrollbarThemeOverlay seems to be built in !use_default_render_theme
builds
> too, so why is this not just in the main unit test file list?

Good catch, I just put it beside the AuraTest without thinking too much. Moved
to main unittest list above.

https://codereview.chromium.org/2590163004/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/scroll/ScrollbarTestSuite.h (right):

https://codereview.chromium.org/2590163004/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/scroll/ScrollbarTestSuite.h:24: // Public to
allow using NiceMock.
On 2016/12/22 15:21:00, jbroman wrote:
> Does protected not work? NiceMock<T> derives from T.

Sure does. Done.

[bokan, 2016-12-22 16:11:03]

The CQ bit was checked by bokan@chromium.org

[bokan, 2016-12-22 16:11:03]

The patchset sent to the CQ was uploaded after l-g-t-m from skobes@chromium.org,
jbroman@chromium.org
Link to the patchset: https://codereview.chromium.org/2590163004/#ps80001
(title: "Fix BUILD.gn, make MockScrollableArea constructor protected")

[commit-bot: I haz the power, 2016-12-22 16:11:16]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-22 18:03:06]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1482423063192790,
"parent_rev": "9b558a52b237130ec5dcdbfdce238d57eb3b0738", "commit_rev":
"4a4c30bf1e1b2dd50f415eae6d3f4005519db136"}

[commit-bot: I haz the power, 2016-12-22 18:03:32]

Description was changed from

==========
Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

We still invalidate the scroll controls on ScrollableArea, which is used if the
scrollbars are painted into the ScrollableArea itself, rather than composited
layers.

The thumbNeedsRepaint property on Scrollbar is used to repaint a scrollbar thumb
that's actually changed appearance. This isn't actually needed when the thumb
simply changes scroll offset. Nor is it needed when the enabled/disabled state
changes since the compositor knows how to hide them itself. Thus, a composited
scrollbar now needs to repaint only when the hovered or pressed state changes
or if there's a geometry change.

BUG=669670
==========

to

==========
Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

We still invalidate the scroll controls on ScrollableArea, which is used if the
scrollbars are painted into the ScrollableArea itself, rather than composited
layers.

The thumbNeedsRepaint property on Scrollbar is used to repaint a scrollbar thumb
that's actually changed appearance. This isn't actually needed when the thumb
simply changes scroll offset. Nor is it needed when the enabled/disabled state
changes since the compositor knows how to hide them itself. Thus, a composited
scrollbar now needs to repaint only when the hovered or pressed state changes
or if there's a geometry change.

BUG=669670

Review-Url: https://codereview.chromium.org/2590163004
==========

[commit-bot: I haz the power, 2016-12-22 18:03:33]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-12-22 18:05:29]

Description was changed from

==========
Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

We still invalidate the scroll controls on ScrollableArea, which is used if the
scrollbars are painted into the ScrollableArea itself, rather than composited
layers.

The thumbNeedsRepaint property on Scrollbar is used to repaint a scrollbar thumb
that's actually changed appearance. This isn't actually needed when the thumb
simply changes scroll offset. Nor is it needed when the enabled/disabled state
changes since the compositor knows how to hide them itself. Thus, a composited
scrollbar now needs to repaint only when the hovered or pressed state changes
or if there's a geometry change.

BUG=669670

Review-Url: https://codereview.chromium.org/2590163004
==========

to

==========
Aura overlay scrollbars shouldn't invalidate thumb on scroll or enabled state.

We still invalidate the scroll controls on ScrollableArea, which is used if the
scrollbars are painted into the ScrollableArea itself, rather than composited
layers.

The thumbNeedsRepaint property on Scrollbar is used to repaint a scrollbar thumb
that's actually changed appearance. This isn't actually needed when the thumb
simply changes scroll offset. Nor is it needed when the enabled/disabled state
changes since the compositor knows how to hide them itself. Thus, a composited
scrollbar now needs to repaint only when the hovered or pressed state changes
or if there's a geometry change.

BUG=669670

Committed: https://crrev.com/65f5be3dadd8a0a752effd7073a12f9ecdb1c472
Cr-Commit-Position: refs/heads/master@{#440450}
==========

[commit-bot: I haz the power, 2016-12-22 18:05:30]

Patchset 5 (id:??) landed as
https://crrev.com/65f5be3dadd8a0a752effd7073a12f9ecdb1c472
Cr-Commit-Position: refs/heads/master@{#440450}