Disable chrome overlay scrollbar animations

[flackr]

Overlay scrollbar animations are time delayed and not web visible or testable. Disable timed animation delays to ensure ref tests do not fail based on how long it takes to capture the screenshot. In particular, this flag ensures that the overlay scrollbar remains visible indefinitely after a scroll allowing the scrollbar position / appearance to be reliably tested even when overlay scrollbars are in use.

[foolip]

@flackr have you done a full run with this flag to ensure that it only makes additional tests pass and doesn't regress any tests?

[flackr]

@foolip Thanks, I merged with 1a5b135 which had a wpt run for chrome canary and chrome stable and triggered a run. I think all the tests passed except for some infrastructure test which I'm not quite sure I understand, maybe I was supposed to rebase my change on top of the target commit instead or merging?

[foolip]

@flackr do you have a link to the results on wpt.fyi?

maybe I was supposed to rebase my change on top of the target commit instead or merging?

The commit history doesn't matter, as long as the diff between the commit and the one you're comparing to contains only the intended changes, then you got it right.

[foolip]

@flackr I see you rebased and triggered runs on a7ec527. Here's a view of the differences between the master branch and your changes:
https://wpt.fyi/results/?q=is%3Adifferent&run_id=5089997478952960&run_id=5090671721709568

Some of the seeming regressions must be because of flakiness. But is there any regression in there that is plausibly related to scrollbars?

[foolip]

https://wpt.fyi/results/?q=is%3Adifferent%20scroll&run_id=5089997478952960&run_id=5090671721709568 is promising, among tests with "scroll" in the name there are only progressions, no regressions.

[foolip]

@flackr feel free to merge if you see nothing of concern in that diff

[foolip]

Hmm, so the set_get_window_rect.html failure in infrastructure tests will block landing this. But it looks like that failure was in Firefox, and maybe preexisting then?

@past have you seen this blocking other PRs?

[past]

Hmm, so the set_get_window_rect.html failure in infrastructure tests will block landing this. But it looks like that failure was in Firefox, and maybe preexisting then?

@past have you seen this blocking other PRs?

I hadn't seen this before, but it seems to be a recent failure, unrelated to this PR.

[flackr]

@foolip @past what do we need to do to get this unblocked?

[past]

Given that the change is only impacting Chrome, the check failures seem unrelated. It's up to Philip since he started reviewing this.