Make scrollAnimatorEnabled work on Mac like it does on other platforms

Make scrollAnimatorEnabled work on Mac like it does on other platforms

Mac currently has a separate path to enable/disable scroll animations in
Blink. Instead of using the existing Blink setting for scroll animations,
ScrollbarThemeMacCommon sets a flag scrollAnimationEnabledForSystem which
is then checked along side the Blink setting. A side-effect of this is
that --(disable|enable)-scroll-animator doesn't work on Mac and layout
tests default to scroll animations disabled with no way to turn them on.

This patch removes the scrollAnimationEnabledForSystem flag and instead
unifies this setting with how it's handled on other platforms. When Blink
settings are computed, the OSX setting is queried and set into the usual
enable_scroll_animator setting. Changes to the OSX setting cause the
browser process to recalculate and apply new Blink settings.

This allows layout tests to use internals.settings.setScrollAnimatorEnabled
to allow testing of scroll animation semantics on Mac.

BUG=

Committed: https://crrev.com/b9c004266f7f0d0380935dfc8a527bb08409627d
Cr-Commit-Position: refs/heads/master@{#376025}

[bokan, 2016-02-01 17:12:35]

Description was changed from

==========
Make scrollAnimatorEnabled work on Mac like it does on other platforms

Mac currently has a separate path to enable/disable scroll animations in
Blink. Instead of using the existing Blink setting for scroll animations,
ScrollbarThemeMacCommon sets a flag scrollAnimationEnabledForSystem which
is then checked along side the Blink setting. A side-effect of this is
that --(disable|enable)-scroll-animator doesn't work on Mac and layout
tests default to scroll animations disabled with no way to turn them on.

This patch removes the scrollAnimationEnabledForSystem flag and instead
unifies this setting with how it's handled on other platforms. When Blink
settings are computed, the OSX setting is queried and set into the usual
enable_scroll_animator setting. Changes to the OSX setting cause the
browser process to recalculate and apply new Blink settings.

This allows layout tests to use internals.settings.setScrollAnimatorEnabled
to allow testing of scroll animation semantics on Mac.

BUG=
==========

to

==========
Make scrollAnimatorEnabled work on Mac like it does on other platforms

Mac currently has a separate path to enable/disable scroll animations in
Blink. Instead of using the existing Blink setting for scroll animations,
ScrollbarThemeMacCommon sets a flag scrollAnimationEnabledForSystem which
is then checked along side the Blink setting. A side-effect of this is
that --(disable|enable)-scroll-animator doesn't work on Mac and layout
tests default to scroll animations disabled with no way to turn them on.

This patch removes the scrollAnimationEnabledForSystem flag and instead
unifies this setting with how it's handled on other platforms. When Blink
settings are computed, the OSX setting is queried and set into the usual
enable_scroll_animator setting. Changes to the OSX setting cause the
browser process to recalculate and apply new Blink settings.

This allows layout tests to use internals.settings.setScrollAnimatorEnabled
to allow testing of scroll animation semantics on Mac.

BUG=
==========

[bokan, 2016-02-01 17:12:35]

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

[bokan, 2016-02-01 17:14:02]

Hi Greg, I see you've done some related work in
https://codereview.chromium.org/1234783005, could you PTAL? Feel free to forward
this to a better reviewer if you're not the right person.

[bokan, 2016-02-02 19:45:39]

https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
File content/browser/theme_helper_mac.mm (right):

https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
content/browser/theme_helper_mac.mm:167:
static_cast<RenderProcessHostImpl*>(it.GetCurrentValue());
In particular, I'm not sure if this is kosher - will RPH always be a RPHI?

https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
content/browser/theme_helper_mac.mm:211: RenderProcessHostImpl* rphi =
Ditto here

[Greg K, 2016-02-02 19:54:58]

On 2016/02/02 19:45:39, bokan wrote:
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> File content/browser/theme_helper_mac.mm (right):
> 
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> content/browser/theme_helper_mac.mm:167:
> static_cast<RenderProcessHostImpl*>(it.GetCurrentValue());
> In particular, I'm not sure if this is kosher - will RPH always be a RPHI?
> 
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> content/browser/theme_helper_mac.mm:211: RenderProcessHostImpl* rphi =
> Ditto here

Thanks for adding me to this. I am concerned about this change because it
removes the IPC code to send the IPC code to send the scrollbar animation status
from the browser to the renderers. Because of OS X sandboxing, the renderers
should not talk to cfprefsd directly. We have already tightened that and are
trying to completely eliminate calls from the renderers to cfprefsd going
forward.

I'm adding Robert. It does sound like there are some issues to address but we
should fix these without having the renderers query the status directly.

[bokan, 2016-02-02 19:58:41]

On 2016/02/02 19:54:58, Greg Kerr wrote:
> On 2016/02/02 19:45:39, bokan wrote:
> >
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> > File content/browser/theme_helper_mac.mm (right):
> > 
> >
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> > content/browser/theme_helper_mac.mm:167:
> > static_cast<RenderProcessHostImpl*>(it.GetCurrentValue());
> > In particular, I'm not sure if this is kosher - will RPH always be a RPHI?
> > 
> >
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> > content/browser/theme_helper_mac.mm:211: RenderProcessHostImpl* rphi =
> > Ditto here
> 
> Thanks for adding me to this. I am concerned about this change because it
> removes the IPC code to send the IPC code to send the scrollbar animation
status
> from the browser to the renderers. Because of OS X sandboxing, the renderers
> should not talk to cfprefsd directly. We have already tightened that and are
> trying to completely eliminate calls from the renderers to cfprefsd going
> forward.
> 
> I'm adding Robert. It does sound like there are some issues to address but we
> should fix these without having the renderers query the status directly.

In this case though it's the browser process that queries the OSX setting in
RenderViewHostImpl, and sends it to the renderer via WebPreferences. Unless I'm
missing something (entirely possible, I rarely dwell in these parts :)

[Robert Sesek, 2016-02-02 20:02:30]

On 2016/02/02 19:58:41, bokan wrote:
> On 2016/02/02 19:54:58, Greg Kerr wrote:
> > On 2016/02/02 19:45:39, bokan wrote:
> > >
> >
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> > > File content/browser/theme_helper_mac.mm (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> > > content/browser/theme_helper_mac.mm:167:
> > > static_cast<RenderProcessHostImpl*>(it.GetCurrentValue());
> > > In particular, I'm not sure if this is kosher - will RPH always be a RPHI?
> > > 
> > >
> >
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> > > content/browser/theme_helper_mac.mm:211: RenderProcessHostImpl* rphi =
> > > Ditto here
> > 
> > Thanks for adding me to this. I am concerned about this change because it
> > removes the IPC code to send the IPC code to send the scrollbar animation
> status
> > from the browser to the renderers. Because of OS X sandboxing, the renderers
> > should not talk to cfprefsd directly. We have already tightened that and are
> > trying to completely eliminate calls from the renderers to cfprefsd going
> > forward.
> > 
> > I'm adding Robert. It does sound like there are some issues to address but
we
> > should fix these without having the renderers query the status directly.
> 
> In this case though it's the browser process that queries the OSX setting in
> RenderViewHostImpl, and sends it to the renderer via WebPreferences. Unless
I'm
> missing something (entirely possible, I rarely dwell in these parts :)

Does anything in Blink directly or indirectly call into the gfx::Animation
method?

[bokan, 2016-02-02 20:15:54]

On 2016/02/02 20:02:30, Robert Sesek wrote:
> On 2016/02/02 19:58:41, bokan wrote:
> > On 2016/02/02 19:54:58, Greg Kerr wrote:
> > > On 2016/02/02 19:45:39, bokan wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> > > > File content/browser/theme_helper_mac.mm (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> > > > content/browser/theme_helper_mac.mm:167:
> > > > static_cast<RenderProcessHostImpl*>(it.GetCurrentValue());
> > > > In particular, I'm not sure if this is kosher - will RPH always be a
RPHI?
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/1653003002/diff/20001/content/browser/theme_h...
> > > > content/browser/theme_helper_mac.mm:211: RenderProcessHostImpl* rphi =
> > > > Ditto here
> > > 
> > > Thanks for adding me to this. I am concerned about this change because it
> > > removes the IPC code to send the IPC code to send the scrollbar animation
> > status
> > > from the browser to the renderers. Because of OS X sandboxing, the
renderers
> > > should not talk to cfprefsd directly. We have already tightened that and
are
> > > trying to completely eliminate calls from the renderers to cfprefsd going
> > > forward.
> > > 
> > > I'm adding Robert. It does sound like there are some issues to address but
> we
> > > should fix these without having the renderers query the status directly.
> > 
> > In this case though it's the browser process that queries the OSX setting in
> > RenderViewHostImpl, and sends it to the renderer via WebPreferences. Unless
> I'm
> > missing something (entirely possible, I rarely dwell in these parts :)
> 
> Does anything in Blink directly or indirectly call into the gfx::Animation
> method?

No, I added the method in this CL and the only caller is in
ComputeWebKitPreferences, but that's a good point, I'll add an ASSERT that we're
in the browser process (if you know how off-hand what that check is let me know)

[bokan, 2016-02-06 22:42:20]

Patchset #6 (id:100001) has been deleted

[Robert Sesek, 2016-02-06 23:31:30]

rsesek@chromium.org changed reviewers:
+ rsesek@chromium.org

[bokan, 2016-02-07 00:53:53]

rsesek@, could you PTAL? I've added a DCHECK that we only call the new method
from the browser thread. The only way I could find to do that from /base was
checking the MessageLoop type. (IO was because unit tests run on a
MessageLoopForIO).

[Robert Sesek, 2016-02-08 17:39:51]

Sorry, I either forgot to add myself to the reviewers list or was somehow
dropped from it, so I didn't see your reply.

https://codereview.chromium.org/1653003002/diff/120001/base/mac/mac_util.mm
File base/mac/mac_util.mm (right):

https://codereview.chromium.org/1653003002/diff/120001/base/mac/mac_util.mm#n...
base/mac/mac_util.mm:607: bool IsScrollAnimationEnabled() {
I don't think this needs to be in base, since it's only called in //ui/gfx. Just
create animation_mac.mm to implement ScrollAnimationsEnabledBySystem in an
ObjC++ file.

https://codereview.chromium.org/1653003002/diff/120001/third_party/WebKit/pub...
File third_party/WebKit/public/web/mac/WebScrollbarTheme.h (right):

https://codereview.chromium.org/1653003002/diff/120001/third_party/WebKit/pub...
third_party/WebKit/public/web/mac/WebScrollbarTheme.h:52: //
|scrollAnimationEnabled| is the current value of NSScrollAnimationEnabled or
AppleScrollAnimationEnabled from NSUserDefaults.
Remove.

[bokan, 2016-02-08 20:29:05]

Patchset #8 (id:160001) has been deleted

[bokan, 2016-02-08 20:55:06]

Done, ptal.

https://codereview.chromium.org/1653003002/diff/120001/base/mac/mac_util.mm
File base/mac/mac_util.mm (right):

https://codereview.chromium.org/1653003002/diff/120001/base/mac/mac_util.mm#n...
base/mac/mac_util.mm:607: bool IsScrollAnimationEnabled() {
On 2016/02/08 17:39:51, Robert Sesek wrote:
> I don't think this needs to be in base, since it's only called in //ui/gfx.
Just
> create animation_mac.mm to implement ScrollAnimationsEnabledBySystem in an
> ObjC++ file.

Done. I moved the Windows bits into animation_win.cc for consistency too.

https://codereview.chromium.org/1653003002/diff/120001/third_party/WebKit/pub...
File third_party/WebKit/public/web/mac/WebScrollbarTheme.h (right):

https://codereview.chromium.org/1653003002/diff/120001/third_party/WebKit/pub...
third_party/WebKit/public/web/mac/WebScrollbarTheme.h:52: //
|scrollAnimationEnabled| is the current value of NSScrollAnimationEnabled or
AppleScrollAnimationEnabled from NSUserDefaults.
On 2016/02/08 17:39:51, Robert Sesek wrote:
> Remove.
Good catch, thanks! Done.

[Robert Sesek, 2016-02-09 18:57:45]

LGTM

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
File ui/gfx/animation/animation_mac.mm (right):

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation_mac.mm:16: DCHECK(base::MessageLoopForUI::IsCurrent()
||
Not sure about how useful this DCHCEK is. It would be nice to have a
is-browser-only check, but I don't think that's possible to do correctly without
a layering violation.

[bokan, 2016-02-09 19:00:39]

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
File ui/gfx/animation/animation_mac.mm (right):

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation_mac.mm:16: DCHECK(base::MessageLoopForUI::IsCurrent()
||
On 2016/02/09 18:57:45, Robert Sesek wrote:
> Not sure about how useful this DCHCEK is. It would be nice to have a
> is-browser-only check, but I don't think that's possible to do correctly
without
> a layering violation.

AFAICT, renderer processes run on a "custom" message loop so it should catch
calls from the renderer process, right? I'll leave it in unless that's wrong.

[bokan, 2016-02-09 22:44:41]

bokan@chromium.org changed reviewers:
+ avi@chromium.org, chrishtr@chromium.org, kenrb@chromium.org,
vollick@chromium.org

[bokan, 2016-02-09 22:44:42]

kernel@, are you ok with these changes since the calls are still from the
browser process?

+kenrb@: for view_messages.h
+chrishtr@: for WebKit/public/web
+vollick@: for WebKit/Source/platform
+avi@: for content/ and ui/

[Greg K, 2016-02-09 22:55:55]

On 2016/02/09 22:44:42, bokan wrote:
> kernel@, are you ok with these changes since the calls are still from the
> browser process?
> 
> +kenrb@: for view_messages.h
> +chrishtr@: for WebKit/public/web
> +vollick@: for WebKit/Source/platform
> +avi@: for content/ and ui/

Yes, the change seems fine given the additional information. Thanks.

[Avi (use Gerrit), 2016-02-10 00:24:54]

lgtm

Just nits.

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
File ui/gfx/animation/animation.cc (right):

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation.cc:94: // Defined in platform specific file for Win
"... for Windows."

complete sentences, plz

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation.cc:102: // Defined in platform specific files for
Win/Mac
sentences ending in period

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
File ui/gfx/animation/animation_mac.mm (right):

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation_mac.mm:1: // Copyright (c) 2016 The Chromium Authors.
All rights reserved.
no (c)

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
File ui/gfx/animation/animation_win.cc (right):

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation_win.cc:1: // Copyright (c) 2016 The Chromium Authors.
All rights reserved.
no (c)

[Ian Vollick, 2016-02-10 00:31:35]

On 2016/02/10 00:24:54, Avi wrote:
> lgtm
> 
> Just nits.
> 
>
https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
> File ui/gfx/animation/animation.cc (right):
> 
>
https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
> ui/gfx/animation/animation.cc:94: // Defined in platform specific file for Win
> "... for Windows."
> 
> complete sentences, plz
> 
>
https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
> ui/gfx/animation/animation.cc:102: // Defined in platform specific files for
> Win/Mac
> sentences ending in period
> 
>
https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
> File ui/gfx/animation/animation_mac.mm (right):
> 
>
https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
> ui/gfx/animation/animation_mac.mm:1: // Copyright (c) 2016 The Chromium
Authors.
> All rights reserved.
> no (c)
> 
>
https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
> File ui/gfx/animation/animation_win.cc (right):
> 
>
https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
> ui/gfx/animation/animation_win.cc:1: // Copyright (c) 2016 The Chromium
Authors.
> All rights reserved.
> no (c)

platform/ lgtm.

[kenrb, 2016-02-10 15:21:35]

ipc lgtm

[bokan, 2016-02-10 16:31:22]

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
File ui/gfx/animation/animation.cc (right):

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation.cc:94: // Defined in platform specific file for Win
On 2016/02/10 00:24:54, Avi wrote:
> "... for Windows."
> 
> complete sentences, plz

Done.

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation.cc:102: // Defined in platform specific files for
Win/Mac
On 2016/02/10 00:24:54, Avi wrote:
> sentences ending in period

Done.

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
File ui/gfx/animation/animation_mac.mm (right):

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation_mac.mm:1: // Copyright (c) 2016 The Chromium Authors.
All rights reserved.
On 2016/02/10 00:24:54, Avi wrote:
> no (c)

Done.

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
File ui/gfx/animation/animation_win.cc (right):

https://codereview.chromium.org/1653003002/diff/180001/ui/gfx/animation/anima...
ui/gfx/animation/animation_win.cc:1: // Copyright (c) 2016 The Chromium Authors.
All rights reserved.
On 2016/02/10 00:24:54, Avi wrote:
> no (c)

Done.

[bokan, 2016-02-11 19:27:26]

chrishtr@: ptal.

[chrishtr, 2016-02-12 18:24:23]

chrishtr@chromium.org changed reviewers:
+ ccameron@chromium.org

[chrishtr, 2016-02-12 18:24:24]

I went as far back as notifyPrefsChangedWithRedraw in theme_helper_mac.mm to see
where
it was being set from. It appears that this is actually set by the OS X system,
in order to
respect the global scrollbar animation preferences of the user of OS X. Is that
correct?
If so, does this patch break that functionality?

[bokan, 2016-02-12 18:45:27]

On 2016/02/12 18:24:24, chrishtr wrote:
> I went as far back as notifyPrefsChangedWithRedraw in theme_helper_mac.mm to
see
> where
> it was being set from. It appears that this is actually set by the OS X
system,
> in order to
> respect the global scrollbar animation preferences of the user of OS X. Is
that
> correct?
> If so, does this patch break that functionality?

That's correct but this patch doesn't break that functionality (I've tested
manually). This change makes notifyPrefsChangedWithRedraw update the WebKit
preferences in the browser process. The browser process then grabs the value
from the OSX system, puts it in the WebPreferences struct and passes it to the
renderer processes where it makes its way into Blink via WebSettings.

[bokan, 2016-02-16 19:49:55]

chrishtr@: ping.

[chrishtr, 2016-02-16 20:27:05]

lgtm

[bokan, 2016-02-16 21:02:10]

The CQ bit was checked by bokan@chromium.org

[bokan, 2016-02-16 21:02:11]

The patchset sent to the CQ was uploaded after l-g-t-m from kenrb@chromium.org,
avi@chromium.org, vollick@chromium.org, rsesek@chromium.org
Link to the patchset: https://codereview.chromium.org/1653003002/#ps200001
(title: "Addressed comments from avi@")

[commit-bot: I haz the power, 2016-02-16 21:03:54]

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

[commit-bot: I haz the power, 2016-02-16 21:40:11]

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

[commit-bot: I haz the power, 2016-02-16 21:40:12]

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

[bokan, 2016-02-17 21:04:38]

The CQ bit was checked by bokan@chromium.org

[bokan, 2016-02-17 21:04:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org, kenrb@chromium.org, avi@chromium.org,
vollick@chromium.org, rsesek@chromium.org
Link to the patchset: https://codereview.chromium.org/1653003002/#ps220001
(title: "Also add new files to GN build")

[commit-bot: I haz the power, 2016-02-17 21:08:43]

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

[commit-bot: I haz the power, 2016-02-17 21:18:46]

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

[commit-bot: I haz the power, 2016-02-17 21:18:47]

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

[bokan, 2016-02-17 21:22:12]

The CQ bit was checked by bokan@chromium.org

[bokan, 2016-02-17 21:22:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org, kenrb@chromium.org, avi@chromium.org,
vollick@chromium.org, rsesek@chromium.org
Link to the patchset: https://codereview.chromium.org/1653003002/#ps240001
(title: "Previous patch accidentally lost new files")

[commit-bot: I haz the power, 2016-02-17 21:25:22]

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

[commit-bot: I haz the power, 2016-02-17 23:22:17]

Description was changed from

==========
Make scrollAnimatorEnabled work on Mac like it does on other platforms

Mac currently has a separate path to enable/disable scroll animations in
Blink. Instead of using the existing Blink setting for scroll animations,
ScrollbarThemeMacCommon sets a flag scrollAnimationEnabledForSystem which
is then checked along side the Blink setting. A side-effect of this is
that --(disable|enable)-scroll-animator doesn't work on Mac and layout
tests default to scroll animations disabled with no way to turn them on.

This patch removes the scrollAnimationEnabledForSystem flag and instead
unifies this setting with how it's handled on other platforms. When Blink
settings are computed, the OSX setting is queried and set into the usual
enable_scroll_animator setting. Changes to the OSX setting cause the
browser process to recalculate and apply new Blink settings.

This allows layout tests to use internals.settings.setScrollAnimatorEnabled
to allow testing of scroll animation semantics on Mac.

BUG=
==========

to

==========
Make scrollAnimatorEnabled work on Mac like it does on other platforms

Mac currently has a separate path to enable/disable scroll animations in
Blink. Instead of using the existing Blink setting for scroll animations,
ScrollbarThemeMacCommon sets a flag scrollAnimationEnabledForSystem which
is then checked along side the Blink setting. A side-effect of this is
that --(disable|enable)-scroll-animator doesn't work on Mac and layout
tests default to scroll animations disabled with no way to turn them on.

This patch removes the scrollAnimationEnabledForSystem flag and instead
unifies this setting with how it's handled on other platforms. When Blink
settings are computed, the OSX setting is queried and set into the usual
enable_scroll_animator setting. Changes to the OSX setting cause the
browser process to recalculate and apply new Blink settings.

This allows layout tests to use internals.settings.setScrollAnimatorEnabled
to allow testing of scroll animation semantics on Mac.

BUG=
==========

[commit-bot: I haz the power, 2016-02-17 23:22:18]

Committed patchset #11 (id:240001)

[commit-bot: I haz the power, 2016-02-17 23:23:05]

Description was changed from

==========
Make scrollAnimatorEnabled work on Mac like it does on other platforms

Mac currently has a separate path to enable/disable scroll animations in
Blink. Instead of using the existing Blink setting for scroll animations,
ScrollbarThemeMacCommon sets a flag scrollAnimationEnabledForSystem which
is then checked along side the Blink setting. A side-effect of this is
that --(disable|enable)-scroll-animator doesn't work on Mac and layout
tests default to scroll animations disabled with no way to turn them on.

This patch removes the scrollAnimationEnabledForSystem flag and instead
unifies this setting with how it's handled on other platforms. When Blink
settings are computed, the OSX setting is queried and set into the usual
enable_scroll_animator setting. Changes to the OSX setting cause the
browser process to recalculate and apply new Blink settings.

This allows layout tests to use internals.settings.setScrollAnimatorEnabled
to allow testing of scroll animation semantics on Mac.

BUG=
==========

to

==========
Make scrollAnimatorEnabled work on Mac like it does on other platforms

Mac currently has a separate path to enable/disable scroll animations in
Blink. Instead of using the existing Blink setting for scroll animations,
ScrollbarThemeMacCommon sets a flag scrollAnimationEnabledForSystem which
is then checked along side the Blink setting. A side-effect of this is
that --(disable|enable)-scroll-animator doesn't work on Mac and layout
tests default to scroll animations disabled with no way to turn them on.

This patch removes the scrollAnimationEnabledForSystem flag and instead
unifies this setting with how it's handled on other platforms. When Blink
settings are computed, the OSX setting is queried and set into the usual
enable_scroll_animator setting. Changes to the OSX setting cause the
browser process to recalculate and apply new Blink settings.

This allows layout tests to use internals.settings.setScrollAnimatorEnabled
to allow testing of scroll animation semantics on Mac.

BUG=

Committed: https://crrev.com/b9c004266f7f0d0380935dfc8a527bb08409627d
Cr-Commit-Position: refs/heads/master@{#376025}
==========

[commit-bot: I haz the power, 2016-02-17 23:23:06]

Patchset 11 (id:??) landed as
https://crrev.com/b9c004266f7f0d0380935dfc8a527bb08409627d
Cr-Commit-Position: refs/heads/master@{#376025}