Out-of-Process iframes --top-document-isolation process can get blocked by one CPU intensive iframe
Reported by
linus.sc...@gmail.com,
Apr 28 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.82 Safari/537.36 Vivaldi/1.9.818.44 Steps to reproduce the problem: 1. Start chromium with --top-document-isolation enabled 2. Open a first tab that has one OOP iframe. The document in the iframe is not creating any CPU load. ( in reduced testcase file attached this is oopiftest1-noCPUload.html ) 3. Open a second tab that has one OOP iframe (in the testcase it has the same domain as the iframe in step 2). The document in this iframe is creating some CPU load. (in reduced testcase file attached this is oopiftest2-withCPUload.html) 4. Verify in chromium tasks manager looks like this: Tab: 127.0.0.1:3007/examplesnocsp/oopiftest1-noCPUload.html Subframes for: 127.0.0.1:3007/examplesnocsp/oopiftest1-noCPUload.html Subframes for: 127.0.0.1:3007/examplesnocsp/oopiftest2-withCPUload.html Tab: 127.0.0.1:3007/examplesnocsp/oopiftest2-withCPUload.html Please not that X% of CPU load is shown as one aggregated value for the two subframes 5. Close the second tab that you opened in step 3 (the one with the iframe generating the CPU load) 6. Verify in chromium tasks manager looks like this: Tab: 127.0.0.1:3007/examplesnocsp/oopiftest1-noCPUload.html Subframes for: 127.0.0.1:3007/examplesnocsp/oopiftestI-noCPUload.html 7: Issue - The CPU load of X% is still shown for the one and only remaining subframe although this is the OOP frame not generating any CPU load itself What is the expected behavior? The subframe with the CPU load should be killed when its parent tab is closed. I expect in step 7 to see no CPU load for the remaining subframe anymore. What went wrong? Looks like the CPU intensive thread is blocking the process that with top-document-isolation is used for all OOPIF´s Did this work before? No Does this work in other browsers? Yes Chrome version: 58.0.3029.81 Channel: stable OS Version: 10.0 Flash Version: This bug belongs here component:Internals>Sandbox>SiteIsolation
,
May 4 2017
,
May 5 2017
Tested this issue on Ubuntu 14.04 with chrome #58.0.3029.96, launched chrome with argument "--top-document-isolation" Observations: ------------- 1. On loading webpage oopiftest2-withCPUload.html, didn't observe any spike in CPU usage. 2. On loading oopiftest1 & oopiftest2 html pages, in sub-frame-error seeing a message "localhost refused to connect." Attaching a screen-cast for reference. linus.scharnetzki@ Could you please look into it and let us know your observations.
,
May 5 2017
Thank you for looking into this. As seen in your recording you are loading oopiftest2-withCPUload.html via file://. That will not trigger the bug. Please put all files (like oopiftest2-withCPUload.html) into one folder of a webserver that you are running on localhost. On my machine I have a local webserver running on port 3007, the 4 files of the testcase are placed on that webserver so that for example http://127.0.0.1:3007/examplesnocsp/oopiftest1-noCPUload.html will load the expected file into Chrome. If setup like this you will see inside the iframe the message "No Load :-)" (see screenshot attached below). This is required because OutOfProcess iframe functionality is triggered by the domain of the top-level document being different (127.0.0.1) from the iframe domain (localhost). As you can see on my screenshot (situation on screen is after step 7, so second tab is closed already and the issue of CPU load is visible in chromes task-manager): On Windows (you are on Linux, I dont know if is happening there) I just confirmed that the issue is still existing for Chrome Stable Version 58.0.3029.96 (64-bit)
,
May 5 2017
Thank you for providing more feedback. Adding requester "kkaluri@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
,
May 9 2017
,
May 9 2017
Yes, this is a problem, if two subframes share a renderer process, and one subframe becomes unresponsive, the other will stop working as well. I don't think that the subframe that's causing the problem can be killed individually though, it's likely that we'll need to add something like the 'Page Unresponsive' dialog for subframes and just kill the renderer process.
,
May 10 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 8 2018
We don't currently have plans to ship --top-document-isolation, however we are shipping Site Isolation, which will result in the same situation. We already have a hung renderer detection for subframes, so if user tries to interact with a frame and it has not responded in 30 seconds, a dialog will appear. Further, we are adding more hang detection as part of issue 848821, so it looks to me that this particular bug can be resolved as duplicate or dependent on it.
,
Jun 8 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by rbyers@chromium.org
, May 3 2017Labels: -Hotlist-Interop