page visualization very slow after some time it's open
Reported by
maildeal...@gmail.com,
Jun 19 2018
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Example URL: www.facebook.com Steps to reproduce the problem: 1. open your facebook timeline 2. scroll normally 3. go afk for a while or just alt-tab and do something else for 10 minutes 4. come back and facebook (for example) is unusable What is the expected behavior? have just the normal speed. video for example: https://youtu.be/SRrUO9-Kzl0 What went wrong? this is unusable: https://youtu.be/QFz_cuJNubY Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 66.0.3359.117 Channel: n/a OS Version: Linux stretch 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux Flash Version:
,
Jun 19 2018
,
Jun 19 2018
As per comment #0 we have tested this issue on reported chrome version 66.0.3359.117 and latest chrome stable 67.0.3396.87 using Ubuntu 17.10 as we don't have Ubuntu 18.04. Steps: -------- 1. Launched chrome 2. Navigated to given URL "www.facebook.com". 3. Navigated to Facebook timeline and navigated to new tab and came back after 20 minutes. We have observed that the page loading and scrolls normally. @Reporter: As we are unable to reproduce the issue from our end.Can you verify this issue with fresh profile that is not having any extensions and apps or reset all the flags.Could you please upgrade your chrome browser and let us if the issue still persists. You can download latest chrome builds here: "https: //www.chromium.org/getting-involved/dev-channel". Thanks!
,
Jun 19 2018
@phanindra thanks for checking it. I verified the issue with a fresh profile in another system with the same Version 66.0.3359.117 (Developer Build) built on Debian 9.4, running on Debian 9.4 (64-bit) with the same result. I came out with two questions: 1) could it be that the issue might be related with amd drivers? since both systems have amd cards and drivers. 2) please, correct me if I'm wrong: the link you provided in comment #3 is for getting google chrome, but I am currently running chromium (libre)
,
Jun 19 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 20 2018
maildealete@ Thanks for the update. As per comment #4, as the issue is reproducible on Linux Debian 9.4, adding 'TE-NeedsTriageFromHYD' label and requesting Inhouse team to look into the issue and help in further triaging. Thanks..
,
Jun 20 2018
Might be related to bug 854451 .
,
Jun 20 2018
Try recording a trace, save it, and attach the result here. See https://www.chromium.org/developers/how-tos/submitting-a-performance-bug
,
Jun 20 2018
comment #7: I agree, might be related. comment #8: thanks. I will.
,
Jun 21 2018
Yup - trace would be quite helpful.
,
Jun 27 2018
Here is the trace: I wasn't sure about which options I needed to check, so I check them all. the buffer usage reached 100% inmediatly, so I recorded a few seconds starting after the scrolling was already slow, I hope it helps. https://drive.google.com/file/d/18IvMPOq4vJLX3cI2gjmLsFHmnbrv1Y5R/view?usp=sharing
,
Jun 27 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 29 2018
Unable to reproduce this issue on reported version 66.0.3359.117 and latest stable 67.0.3396.99 using debian rodete. Page scroll is normal even after using facebook.com for 15-20 mins. @Reporter: Could you please check the issue on latest stable and let us know the behavior. You can download it from https://www.chromium.org/getting-involved/dev-channel. Thanks!
,
Jul 3
maildealete@: Sorry but the trace you captured has way too much data to sift over with confidence. Could you capture another trace, this time with all the "Record Categories" (left column) checked but none of the "Disabled by Default" categories (right column).
,
Jul 3
Also, could you specify which page you're interacting with in the trace, was it Facebook?
,
Jul 3
Yes, it was facebook.
,
Jul 3
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 4
maildealete@, Thank you but could you please provide a new trace with the "disabled by default" categories all turned off (enabling them adds too much data to the trace) and everything else on.
,
Jul 7
new trace, made with latest dev from google chrome: Version 69.0.3472.3 (Official Build) dev (64-bit) and "disabled by default" options disabled. trace recorded while browsing facebook timeline.
,
Jul 7
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 7
also, note this CPU usage under Chrome's Task Manager
,
Jul 9
Thank you. flackr@, from the trace I see a BeginMainFrame that calls FireAnimationFrame 14,000+ times. Looks like we're somehow stuck in a loop. Could you triage? |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by maildeal...@gmail.com
, Jun 19 2018