Issue metadata
Sign in to add a comment
|
iframe in chrome extension background page is always getting cancelled
Reported by
alok.si...@travenues.com,
Mar 2 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. add a chrome extension with background page 2. try to add an iframe in background page 3. in the network panel verify its status is canceled What is the expected behavior? iframe should load properly it should not get canceled What went wrong? I've tried loading iframe separately on HTML page and its working so, I think this issue has something to do with chrome extension or browser property Did this work before? Yes Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.10.5 Flash Version: this problem is occurring in some chrome browsers, some are working fine
,
Mar 2 2017
,
Mar 3 2017
Could this be related to site isolation for iframes? Marking untriaged to get proper owners.
,
Mar 3 2017
This is likely related to isolating extensions and web content. Can the reporter confirm that the iframe is navigated to a web URL, not an extension one? dgozman@, it might be related to transfer navigations, which are used when navigating cross-process in this case. The navigation in the new renderer process and the old one are matched up in the browser process, but the old one ends up being canceled. I wonder if DevTools gets confused by that and displays it as cancelled.
,
Mar 3 2017
Yes, we show cancelled one in DevTools, but we should get a successful one from the new process as well. I'd show both for now, because that's what really happens, and we don't want to abstract our users too much from the real thing.
,
Mar 3 2017
Also, transfer navigations are not a thing with PlzNavigate, which is getting closer to done, so it won't be there forever.
,
Mar 3 2017
Assigning to nasko@ for triage.
,
Mar 3 2017
#c7, isn't the content of #c5 basically stating that the two network requests show up in DevTools and one of them is cancelled, the other one successful. It seems that this is working-as-intended as of now with transfers being used for cross-process navigations in subframes.
,
Mar 4 2017
Hey. The reporting team member here. 1) The iframe URL is a web URL not an iframe one. 2) Inserting iframe with that URL in the "New tab" page generates a cancelled request too. Even though the site show up as an iframe on the page, the DOM is not present in the "Element" panel on the DevTools. 3) The DOM ready event for the iframe site is never fired.
,
Mar 6 2017
All the problems described in #c9 are related to inspecting OOPIF from the save DevTools. Merging to 652783. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by mila...@trivunovic.com
, Mar 2 2017