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

Issue 854054 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Compat



Sign in to add a comment

page visualization very slow after some time it's open

Reported by maildeal...@gmail.com, Jun 19 2018

Issue description

UserAgent: 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:
 
in both videos i'm scrolling with mouse wheel. after some time, it's unusable laggy.
Labels: Needs-Milestone
Cc: phanindra.mandapaka@chromium.org
Components: Blink>Scroll
Labels: Needs-Feedback Triaged-ET
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!

@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)

Project Member

Comment 5 by sheriffbot@chromium.org, Jun 19 2018

Labels: -Needs-Feedback
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
Labels: TE-NeedsTriageFromHYD
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..

Comment 7 by woxxom@gmail.com, Jun 20 2018

Might be related to  bug 854451 .

Comment 8 by woxxom@gmail.com, 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
comment #7: I agree, might be related.
comment #8: thanks. I will.

Comment 10 by bokan@chromium.org, Jun 21 2018

Cc: bokan@chromium.org
Labels: Needs-Feedback
Yup - trace would be quite helpful.
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
Project Member

Comment 12 by sheriffbot@chromium.org, Jun 27 2018

Labels: -Needs-Feedback
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
Labels: -TE-NeedsTriageFromHYD Needs-Feedback
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!
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).  
Also, could you specify which page you're interacting with in the trace, was it Facebook?
Yes, it was facebook.
Project Member

Comment 17 by sheriffbot@chromium.org, Jul 3

Cc: sindhu.chelamcherla@chromium.org
Labels: -Needs-Feedback
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
Labels: Needs-Feedback
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.
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.


trace_1.json.gz
5.2 MB Download
Project Member

Comment 20 by sheriffbot@chromium.org, Jul 7

Labels: -Needs-Feedback
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
also, note this CPU usage under Chrome's Task Manager
task manager
73.8 KB View Download
Owner: flackr@chromium.org
Status: Assigned (was: Unconfirmed)
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