New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 638212 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Economists animation stops running if you scroll the page

Project Member Reported by skyos...@chromium.org, Aug 16 2016

Issue description

To reproduce:

1. Open http://www.andyfoulds.co.uk/amusement/economists.htm
2. Drag using the mouse => animation works fine.
3. Scroll up or down using the mouse wheel.
4. Drag again => animation stops.

Looks like the scroll is taking us from MAIN_THREAD_CUSTOM_INPUT_HANDLING to SYNCHRONIZED_GESTURE, which causes expensive timers to be deferred.
 
trace_economist.json.gz
5.5 MB Download
Status: Started (was: Available)
Fix here: https://codereview.chromium.org/2266883002
Project Member

Comment 3 by bugdroid1@chromium.org, Aug 22 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1329d0ac5e235bd6a94ef3ac22947ea6acf67363

commit 1329d0ac5e235bd6a94ef3ac22947ea6acf67363
Author: skyostil <skyostil@chromium.org>
Date: Mon Aug 22 18:04:48 2016

scheduler: Reset gesture state at start of a mouse drag

This patch fixes a bug where the scheduler did not reset gesture
tracking state when a new mouse drag gesture was started. This meant
that an unrelated gesture (e.g., a wheel scroll) could be used to
compute the policy for the mouse drag, potentially causing tasks
necessary to the gesture (e.g., timers) to get deferred.

We now consider a left button press as the start of a new gesture and
also keep track of which thread is processing the mouse move events
as we do with touch gestures.

BUG= 638212 

Review-Url: https://codereview.chromium.org/2266883002
Cr-Commit-Position: refs/heads/master@{#413475}

[modify] https://crrev.com/1329d0ac5e235bd6a94ef3ac22947ea6acf67363/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc
[modify] https://crrev.com/1329d0ac5e235bd6a94ef3ac22947ea6acf67363/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.h
[modify] https://crrev.com/1329d0ac5e235bd6a94ef3ac22947ea6acf67363/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl_unittest.cc

Status: Fixed (was: Started)
We might want to backport this after a few days.
Labels: Merge-Request-53
Requesting a merge to M53.

Comment 6 by dimu@chromium.org, Aug 26 2016

Labels: -Merge-Request-53 Merge-Review-53 Hotlist-Merge-Review
[Automated comment] Less than 2 weeks to go before stable on M53, manual review required.

Comment 7 by gov...@chromium.org, Aug 26 2016

Before we approve merge to M53, Could you please confirm whether this change is baked/verified in Canary and safe to merge? Please note that M53 is very close to Stable launch and bar is VERY high, we take this change ONLY if it is critical and safe.

Also is this change applicable to all OS or any specific OS?
Labels: OS-All
On second thought, given M52 shipped with this bug and we haven't heard too many complaints (there have been some), let's ship this in M54 instead.

This is for all OSs (updated the flags).

Comment 9 by gov...@chromium.org, Aug 26 2016

Labels: -Merge-Review-53
Thank you, removing "Merge-Review-53" label based on comment #8.

Sign in to add a comment