New issue
Advanced search Search tips

Issue 643435 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Dec 3
Cc:
rohitrao@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Compat



Sign in to add a comment

Tab freezing on DOM update

Reported by n...@azuqua.com, Sep 1 2016 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36

Example URL:

Steps to reproduce the problem:
It's repeatable, but I can't narrow down the case to something I can distribute. I'm happy to share logs and traces, or even give someone temporary access to our alpha environment with instructions to repeat it.

What is the expected behavior?
For the tab not to freeze.

What went wrong?
The tab freezes and cannot be closed.

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: 53.0.2785.89  Channel: stable
OS Version: OS X 10.10.5
Flash Version: 

trace: https://www.dropbox.com/s/6uuinls0o81rv3p/trace_azuqua.json.gz?dl=0

Look for pid 3298, you can see where the freeze happens.

This bug happens in the current version of Chrome as well as Chrome Canary.

Comment 1 by rohitrao@chromium.org, Sep 2 2016

Labels: Needs-Feedback
Can you be more specific about what you mean by "freeze"?  Does the tab stop responding to events?  Does the whole browser stop responding to events?  Do you get a beachball?

Can you close other tabs while in this state?  If you wait for a minute or two, will the frozen tab eventually close?

(Assuming that the browser itself remains responsive, we should forcibly kill the renderer eventually, which should let the tab close?)

Comment 2 by n...@azuqua.com, Sep 2 2016 

Yeah sorry. The tab becomes totally unresponsive. Other tabs are unaffected. Normal cursor. Sometimes the tab will close a while after I tried to close it, sometimes I get the alert that let's me close it, if I switch tabs the hanging one will chew 100% CPU indefinitely.

I've replicated with both extensions and plugins disabled in the current version of Chrome and Canary.
Project Member

Comment 3 by sheriffbot@chromium.org, Sep 10 2016

Labels: -Needs-Feedback Needs-Review
Owner: rohitrao@chromium.org
Thank you for providing more feedback. Adding requester "rohitrao@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Comment 4 by ellyjo...@chromium.org, Sep 13 2016

Cc: rohitrao@chromium.org
Owner: ccameron@chromium.org
Status: Assigned (was: Unconfirmed)
The only thing that looks strange about pid 3298 in that trace is that we spend a great deal of time (like, a few seconds) in cc::DisplayItemList. ccameron@, can we extract any sense from this trace? Over to you for a look.

Comment 5 by ccameron@chromium.org, Sep 28 2016 

Oh, cc::DisplayItemList isn't an event.

Not clear to me. Is this Mac-specific?

Comment 6 by cda...@chromium.org, Mar 13 2017

Labels: -Needs-Review
Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919

Comment 7 by ccameron@chromium.org, May 3 2017

Owner: ----
Status: Untriaged (was: Assigned)

Comment 8 by dtapu...@chromium.org, Nov 1

Labels: Needs-Feedback
This looks like a stale issue. Does it still occur or can we close it out?

Comment 9 by ellyjo...@chromium.org, Dec 3

Status: WontFix (was: Untriaged)
Mac triage: let's WontFix this - we don't have actual repro steps and there's no way we can learn anything from a two-year-old trace.
►

Sign in to add a comment