Issue metadata
Sign in to add a comment
|
DevTools: [oopif] Cannot debug iframes loaded from local extension sources
Reported by
lep...@gmail.com,
Feb 28 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/602.4.8 (KHTML, like Gecko) Version/10.0.3 Safari/602.4.8 Steps to reproduce the problem: 1. Load attached dev extension 2. Refresh a webpage so extension content scripts run (something simple like google.com works) 3. debugger; statements do not pause What is the expected behavior? The `debugger;` statements in both `container.js` and the JSFiddle demo site would have paused the debugger. What went wrong? Our company has a browser extension that injects iframes into the current website that people are viewing. The content scripts create an iframe in the document, and point the source to our application over https (which happens to be a small Ember.js application). I was trying to debug the Ember app today, but found that none of my debugger statements or log statements were being executed. This makes debugging nearly impossible... I have attached a small browser extension that replicates my issue on a much smaller scale. The extension will create an iframe via content scripts, where its source is a local .html file packaged in the extension. The iframe then creates another iframe that points to a simple JSFiddle with debugger; statements that never break when the developer tools are open. Did this work before? Yes 54 Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.12.3 Flash Version: I tested this in Chrome 58 and it still does not work. I also know that this iframe in and iframe method seems totally wonky... but it works for our needs and we're not doing evil things here.
,
Feb 28 2017
Bisect: 414854 (good) - 414880 (bad), 55.0.2842.0 https://chromium.googlesource.com/chromium/src/+log/2bff664c..9738e829?pretty=fuller Suspecting r414879 "Enable Site Isolation for Extensions" Confirmation: in the affected builds rightclick the iframe, choose Inspect - a new devtools debugger pops up - press F5 in this new devtools window to reload the iframe, and now the "debugger" statement with "// This debugger will not break!" comment will work. Explanation: with the extension isolated its iframe is handled by a separately running chrome process so it can't be debugged in devtools attached to the site process.
,
Feb 28 2017
Are you saying you inject iframe into the user's page and it doesn't break upon debugger; in page's inspector?
,
Feb 28 2017
#3, yes, I'm also saying this, and it's easily reproducible, see the bisect above.
,
Feb 28 2017
With the current devtools architecture it simply can't break in the devtools attached to the main site process because the extension is running in a separate process which requires opening its own devtools as explained in #2.
,
Feb 28 2017
Was this a recent change in the devtools architecture? If yes, was it documented anywhere? Not blaming, just trying to find out if this is a change that I should have known about. Thanks
,
Feb 28 2017
>Was this a recent change in the devtools architecture? devtools was always per-process, nothing has changed in this regard. The "Site Isolation for Extensions" change makes the iframe of the extension run in a separate process debugging which requires, obviously, a separate devtools instance and you need to invoke it manually, see #2.
,
Feb 28 2017
The obvious downside of the new behavior is that you need to reload the iframe after invoking a new devtools window manually, in case you want to catch something that happens during the load phase. Currently there seems to be no way of showing devtools automatically for iframe running in an isolated process right after it was added to DOM and started loading its contents similarly to the old existing option "Auto-open devtools for popups".
,
Mar 1 2017
Ah, ok, I did not realize that it was OOPIF-specific. >> With the current devtools architecture it simply can't break in the devtools attached to the main site process because the extension is running in a separate process which requires opening its own devtools as explained in #2. woxxom@: That's not so, DevTools is capable of working with arbitrary processes, it is just a bug that needs to be fixed. lepolt@: Thanks for reporting!
,
Mar 1 2017
>DevTools is capable of working with arbitrary processes, it is just a bug that needs to be fixed. I wonder if this means that OOPIF will be expandable in Elements inspector as well as other parts of the currently shown devtools without the need to open a per-frame devtools window? Sounds good if so!
,
Mar 1 2017
>> I wonder if this means that OOPIF will be expandable in Elements inspector as well as other parts of the currently shown devtools without the need to open a per-frame devtools window? Sounds good if so! DOMs will be stacked so far, but yes, all will be available in a single instance.
,
Mar 6 2017
The work is ongoing under DevTools experiment. See issue 652783 . |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by lep...@gmail.com
, Feb 28 2017