Issue metadata
Sign in to add a comment
|
Chrome idle even with outstanding events.
Reported by
dtipp...@pdftron.com,
May 11 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: 1. Open http://pdftron.s3.amazonaws.com/custom/ID-zJWLuhTffd3c/google/ChromeIdleBugReport/index.html in Chrome. 2. Use the mouse wheel (down and up) to switch pages and then wait for the pages to render. What is the expected behavior? The next pages show up quickly (under a second) as they do on Firefox, Edge and to a lesser extent IE11. What went wrong? The pages generally take seconds to load which is way slower than expected, especially in Chrome. ;) Did this work before? N/A Chrome version: 58.0.3029.110 Channel: stable OS Version: 10.0 Flash Version: Additional profiling and investigation has shown: 1. A great deal of idle time in Chrome 2. A setTimeout(func,80); event that takes seconds to load despite, according to the debugger, nothing else running on the main thread. Interestingly switching pages with the up and down arrows does not exhibit this same behaviour despite running essentially the same code.
,
May 12 2017
,
May 12 2017
Tested the issue on windows 7,Ubuntu 14.04 and Mac 10.12.4 using chrome version 58.0.3029.110. 1.Opened http://pdftron.s3.amazonaws.com/custom/ID-zJWLuhTffd3c/google/ChromeIdleBugReport/index.html 2.Use mouse to go up and down 3.Observed some pages rendering slowly Please find the attached screen cast for the same.But observed the same behaviour on Firefox as well. Please confirm if anything missed here in triaging the issue. Thanks,
,
May 12 2017
Please see the attached video for an example of what we have been seeing. (move the mouse wheel a little and wait for the pages to render) Note that at some point during the video the problem stops occurring. It sometimes will work properly on our machines and usually the problem will occur once again after refreshing the page. It does seem likely there are some timing aspects to this issue. However, the problem has been reproducible on multiple fast Windows 10 machines and even on a Windows 7 machine. We were unable to reproduce the problem on Mac OSX.
,
May 12 2017
Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 15 2017
Could you record a trace as described here and attach it to this bug? https://www.chromium.org/developers/how-tos/submitting-a-performance-bug
,
May 15 2017
,
May 15 2017
Please see the attached performance trace. This was generated by scrolling a page and waiting for the render operation to complete and repeating the operation once.
,
May 15 2017
Thank you for providing more feedback. Adding requester "dtapuska@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 16 2017
Thanks for the trace! Looks like the problem is that the 'wheel' event handler isn't calling event.preventDefault(), so browser tries to scroll the page and ends up deferring some long running timers for a short delay. Adding a call to preventDefault() solves the problem. I noticed that we're not reporting this intervention for wheel events due to a bug -- fix here: https://chromium-review.googlesource.com/c/505617
,
May 16 2017
,
May 17 2017
Thanks for the workaround! It is rather interesting that the delay seen is 2-3 seconds. Is that just the deferral you are mentioning?
,
May 17 2017
Yes, that 2 second delay comes from this constant: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/scheduler/renderer/user_model.h?rcl=138bedb6930d9d7adc9e261133e869f1ee98419d&l=61
,
May 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6548eeb177e2f44766d9f6da7a7bdedf410a3dc0 commit 6548eeb177e2f44766d9f6da7a7bdedf410a3dc0 Author: Sami Kyostila <skyostil@chromium.org> Date: Wed May 17 12:50:51 2017 scheduler: Report timer deferral intervention for wheel events The scheduler can defer long running tasks as timers in order to improve input handling smoothness for touch and mouse wheel events. To help developers find out that this is happening, we log a console message the first time a task is delayed. However we never reported this intervention for wheel gestures because the reporting logic was only considering touch events. This patch corrects the problem. BUG= 721566 Change-Id: Ida0fc479cea17504f735443be9a9488a29d057c3 Reviewed-on: https://chromium-review.googlesource.com/505617 Commit-Queue: Sami Kyöstilä <skyostil@chromium.org> Reviewed-by: Alex Clarke <alexclarke@chromium.org> Cr-Commit-Position: refs/heads/master@{#472434} [modify] https://crrev.com/6548eeb177e2f44766d9f6da7a7bdedf410a3dc0/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc [modify] https://crrev.com/6548eeb177e2f44766d9f6da7a7bdedf410a3dc0/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.h [modify] https://crrev.com/6548eeb177e2f44766d9f6da7a7bdedf410a3dc0/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl_unittest.cc
,
May 17 2017
,
May 29 2017
The NextAction date has arrived: 2017-05-29 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dtipp...@pdftron.com
, May 11 2017