New issue
Advanced search Search tips

Issue 836877 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

A certain combination of CSS transitions causes tab to hang

Reported by poor...@gmail.com, Apr 25 2018

Issue description

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

Example URL:
see attached HTML file

Steps to reproduce the problem:
1. Open the attached HTML file (chrome-crash.html) in a Chrome tab
2. Click on "click here", or otherwise add the "clicked" class to the ".clickable" div (eg in the Inspector)

What is the expected behavior?
The :before gets rotated 90 degrees, per the CSS rule.

What went wrong?
1. The tab appears to hang and doesn't respond to clicks etc.
2. After a while the "wait or exit" dialog appears
3. Looking at the tab's process in the Chrome Task Manager shows that the tab pegs the CPU to 100 and its memory usage goes through the roof.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes Previous release in the Stable channel (ie Chrome 65)

Does this work in other browsers? Yes

Chrome version: 66.0.3359.117  Channel: stable
OS Version: OS X 10.13.4
Flash Version: 

Reproduced on multiple machines in multiple OSes (both OSX and Windows).

I observed this bug in the wild (ie, on a page on the site I develop). The enclosed HTML is the result of my attempts to minimise the amount of markup required to reproduce the bug. I expect it probably isn't a fully minimal repro, but I did my best; the attached HTML represents the point at which everything I tried to remove caused the bug to go away.

I attempted to collect a crash log, per the instructions in the wiki, but I couldn't seem to make it write out the file upon killing the process. I can provide a core dump if necessary. (Too big to upload in this form.)
 
chrome-crash.html
794 bytes View Download

Comment 1 by woxxom@gmail.com, Apr 25 2018

Bisect info: 532647 (good) - 532660 (bad)
https://chromium.googlesource.com/chromium/src/+log/c37f5b8b..7f9b9c15?pretty=fuller
Suspecting r532650 = f89ae106e06d15200d783cb6950961ba999edebe = https://crrev.com/c/858299 by trchen@chromium.org
"[Blink/SPv1] Move composited clip-path to share layer with masks"
Landed in 66.0.3335.0

In the attached dump file for r532660 the tab thread id is 0x3938.
r532660 dumpfile.zip
63.6 KB Download
Components: -Blink Blink>Paint
Labels: -Type-Bug Type-Bug-Regression
Owner: trchen@chromium.org
Status: Assigned (was: Unconfirmed)
Assigning based on bisect.

Comment 4 by trchen@chromium.org, Apr 27 2018

Cc: sunxd@chromium.org
I think we are creating tons of tiles backed with textures.

+sunxd@ do you remember if we do any occlusion check for mask layer tiles?

Comment 5 by poor...@gmail.com, Jun 14 2018

Any news on this bug? Appears that it still occurs in Chrome 67.
Owner: danakj@chromium.org
I'm leaving the team thus re-assigning.

Currently the mask layer doesn't inherit occlusion state from its host layer. This resulted in creating too many tiles if there is a huge composited element with mask.

Note: BGPT will be using kDstIn blending for masks instead of the mask layer, so maybe the bug will be automatically fixed.
Cc: danakj@chromium.org enne@chromium.org
Owner: weiliangc@chromium.org
wei would you like to have a look?

Sign in to add a comment