New issue
Advanced search Search tips

Issue 763665 link

Starred by 5 users

Issue metadata

Status: Archived
Owner: ----
Closed: Nov 1
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

extension badge counters on one page impact performance of whole browser

Reported by sysco...@gmail.com, Sep 9 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce the problem:
1. Have two extensions with badge counters (just to make sure the effect is noticeable enough; it's there with one)
2. Open a link to a heavy counter-incrementing page in a new background tab
3. Keep scrolling through the current page, discover that Chrome stalls and won't scroll and can take several seconds to recover, on a 2017 Macbook Pro (machine not underpowered)

Example extensions and site: Ghostery, HTTPS Everywhere; vs nytimes.com.

Disabling badge counters "mostly resolves" the problem.
The badges are not even being visibly updated because they're the counts for another tab, not the current tab.

It "smells like" there's a global lock being taken for every badge counter update, which happens inline, and the lock is in the same thread as whatever handles basic UI operations like scrolling.

Opening five tabs on nytimes.com articles is enough to have Chrome on a current high-end macbook pro become unusable for up to half a minute.

This might be related to issue 505676.

I refuse to reenable the badge counters to double-check, but I think I saw something like 130 cookies tracked by ghostery and 70 different domains tracked by https everywhere, for one article page load on nytimes.com.  200+ badge updates for one page load.

What is the expected behavior?
Viewing current page should be unaffected by having opened other pages in the background.  I should be able to scroll and read content.

What went wrong?
Browser becomes unusable while it catches up.
System is not maxed out, can use other apps just fine, it's just Chrome.

Did this work before? No 

Chrome version: 60.0.3112.113  Channel: stable
OS Version: OS X 10.12.6
Flash Version:
 
Components: -UI Platform>Extensions
Labels: Performance
Labels: Needs-Triage-M60
Labels: -Performance -Needs-Triage-M60 Performance-Responsiveness
Cc: kebalaji@chromium.org
Labels: Needs-Milestone Needs-Feedback
Unable to reproduce the issue with the below mentioned steps on reported version 60.0.3112.113 and on latest canary 63.0.3232.0 on Mac, Windows 10 and Ubuntu 14.04:
1. Installed Ghostery and HTTPS Everywhere extensions
2. Opened 5 tabs of nytimes.com
3. Badge counter reading is showing as attached in screencast

@Reporter: Could you let us know if we missed any steps from our end and Please upgrade the chrome version to latest Stable, and retry the scenario. If the issue still persist please provide the detail steps and If possible guide us with the screencast or actual and expected screenshots to reproduce the issue from TE end

Thanks!
763665.ogv
31.4 MB Download

Comment 5 by sysco...@gmail.com, Oct 5 2017

In this screencap, you had one complete load of all the NY Times website, let it completely load, and then left it enough time to open each tab without doing any scrolling in the first one, so that by the time you tried to scroll, there had been time for things to work.  You weren't exercising the scrolling during the loading.

In the scenario which hits me, I have an email from NYTimes or other places, with links to articles, which I'm reading in Gmail and am scrolling through the mail to get the links, with immediate scrolling after command-clicking to open the tab.  I'm trying to use the browser's scroll system while the background tab is still loading the remote site.  Command-click to open, scroll.

I won't have time to retry today, will try to get to it soon.

Thanks for looking.
Project Member

Comment 6 by sheriffbot@chromium.org, Oct 5 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kebalaji@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

Comment 7 by ajha@chromium.org, Nov 1 2017

Cc: rdevlin....@chromium.org
Labels: TE-NeedsTriageHelp
Cc'ing 	rdevlin.cronin@ from Issue 505676 for more inputs on this.
Project Member

Comment 8 by sheriffbot@chromium.org, Nov 1

Status: Archived (was: Unconfirmed)
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment