New issue
Advanced search Search tips

Issue 834774 link

Starred by 1 user

Issue metadata

Status: Duplicate
Owner:
Closed: Aug 15
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-08-27
OS: Mac
Pri: 2
Type: Compat



Sign in to add a comment

High CPU consumption on background tab

Project Member Reported by dbesso...@yandex-team.ru, Apr 19 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15

Example URL:
https://flytothesky.ru/5-fraz-kotorye-govoryat-manipulyatory-chtoby-svesti-vas-s-uma/?utm_referrer=https%3A%2F%2Fzen.yandex.com

Steps to reproduce the problem:
1. Open the URL provided, wait for page load (it may take up to 15 seconds)
2. Put mouse cursor into middle of the page content
3. Press Cmd+T to open new tab
4. In the new tab, open about:tracing and collect "Javascript and rendering" traces for several seconds

What is the expected behavior?
There is none to low work on opened page.

What went wrong?
Some mouse event is repeatedly processed causing re-layouts and high power consumption.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? N/A 

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 66.0.3359.0  Channel: dev
OS Version: OS X 10.12.6
Flash Version: Not installed

Everything works as expected when new tab is open with mouse/touchpad.
 
bug.png
567 KB View Download
Labels: Needs-Triage-M66
I've noticed a difference between Mac & Windows.
On Windows, even if the tab is switched using the keyboard, MouseLeave event is passed to renderer. On Mac, there is no such event in the same circumstances.
Components: Blink>Input
Status: Untriaged (was: Unconfirmed)
Mac triage: Per #2, marking for Blink>Input triage.

Comment 4 by bokan@chromium.org, Apr 26 2018

Cc: bokan@chromium.org
Components: -Blink>Input Blink>Scheduling
I'm unable to try this on a Mac but everything appears as expected on Win/Linux. This seems like a scheduling/tab backgrounding issue so over to scheduling.
Owner: bokan@chromium.org
Status: Assigned (was: Untriaged)
Nice catch!

I got a repro on Mac (see attached trace).

We're firing a lot of mouse move events: MouseEventManager::fakeMouseMoveEventTimerFired. It seems that the right option is to stop firing them when we are in the background.

So back to input team.
trace_user_interaction_background.json.gz
1.8 MB Download
Components: Blink>Input

Comment 7 by bokan@chromium.org, Apr 26 2018

Owner: nzolghadr@chromium.org
Thanks for finding that, Navid - could someone familiar with mouse events take a look?
NextAction: 2018-08-27
Navid, could you take a look?
Mergedinto: 855576
Status: Duplicate (was: Assigned)
The NextAction date has arrived: 2018-08-27
Hello, could you please provide an access for me to https://bugs.chromium.org/p/chromium/issues/detail?id=855576?
You might want to look at issue 877132 which is going to make issue 855576 obsolete as it is going remove the timer altogether.
Thank you, I'll take a look at that issue.

Sign in to add a comment