Bug 234456 – Read the default value of the ScrollAnimatorEnabled setting from NSUserDefaults

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Simon Fraser (smfr)]

Read the default value of the ScrollAnimatorEnabled setting from NSUserDefaults

[Simon Fraser (smfr)]

Created attachment 447498 [details]
Patch

[Simon Fraser (smfr)]

Created attachment 447510 [details]
Patch

[Simon Fraser (smfr)]

https://trac.webkit.org/changeset/287228/webkit

[Radar WebKit Bug Importer]

<rdar://problem/86679058>

[Sam Weinig]

Comment on attachment 447510 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=447510&action=review

> LayoutTests/fast/dom/horizontal-scrollbar-in-rtl.html:36
> +                if (window.internals)
> +                    internals.settings.setScrollAnimatorEnabled(false);

Is there a benefit here to using the internals function rather than a header <!-- webkit-test-runner [ ScrollAnimatorEnabled=false ] -->?

My preference is to prefer the comment command over programatic except in cases where either dynamic changes are needed or we are modifying an external test via some platform hook function.

[Sam Weinig]

Comment on attachment 447510 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=447510&action=review

> Source/WebKit/Shared/Cocoa/WebPreferencesDefaultValuesCocoa.mm:71
> +    return [[NSUserDefaults standardUserDefaults] boolForKey:@"NSScrollAnimationEnabled"];

I think this will give weird / unexpected behavior if this returns different values for the WebProcess and the UIProcess (a quirk of the preferences where we don't serialize values that have the default value when sending them to the web process).

Is there a guarantee that NSScrollAnimationEnabled is set the same in both processes?

[Simon Fraser (smfr)]

(In reply to Sam Weinig from comment #5)
> Comment on attachment 447510 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=447510&action=review
> 
> > LayoutTests/fast/dom/horizontal-scrollbar-in-rtl.html:36
> > +                if (window.internals)
> > +                    internals.settings.setScrollAnimatorEnabled(false);
> 
> Is there a benefit here to using the internals function rather than a header
> <!-- webkit-test-runner [ ScrollAnimatorEnabled=false ] -->?
> 
> My preference is to prefer the comment command over programatic except in
> cases where either dynamic changes are needed or we are modifying an
> external test via some platform hook function.

The header comment didn't work (because this is not an internal or experimental feature). That was what I tried initially.

[Sam Weinig]

(In reply to Simon Fraser (smfr) from comment #7)
> (In reply to Sam Weinig from comment #5)
> > Comment on attachment 447510 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=447510&action=review
> > 
> > > LayoutTests/fast/dom/horizontal-scrollbar-in-rtl.html:36
> > > +                if (window.internals)
> > > +                    internals.settings.setScrollAnimatorEnabled(false);
> > 
> > Is there a benefit here to using the internals function rather than a header
> > <!-- webkit-test-runner [ ScrollAnimatorEnabled=false ] -->?
> > 
> > My preference is to prefer the comment command over programatic except in
> > cases where either dynamic changes are needed or we are modifying an
> > external test via some platform hook function.
> 
> The header comment didn't work (because this is not an internal or
> experimental feature). That was what I tried initially.

Header comments should be working for any type of preference. It does not need to be experimental or internal.