New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 816468 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 755515
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Devtools: Can't "inspect element" of extension-page loaded as iframe on remote webpage

Reported by ghuczyn...@gmail.com, Feb 26 2018

Issue description

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

Steps to reproduce the problem:
"Inspect element" doesn't work for elements of an extension-page, when it is loaded as an iframe on a remote webpage.

Example extension is attached.

I believe this is linked to OOPIF. Parent bug for OOPIF DevTools work:
https://bugs.chromium.org/p/chromium/issues/detail?id=652783

I also created a similar (but different) issue:
"Devtools: Can't "inspect element" of iframe loaded on extension page":
https://bugs.chromium.org/p/chromium/issues/detail?id=816455

Example extension
=============

1. Drop all the attached files into a folder, and load the folder as an extension.
2. Click the extension "M" button top right. This will:
- Open a remote webpage of https://chrome-bugs.neocities.org/loaded-iframe.html
- A content script will then load an extension file (iframe.html) as an iframe on the remote webpage.
3. Open 'Developer Tools'
4. Click 'Select an element in the page to inspect it'
5. Try selecting an element in the iframe-loaded extension page - you can't.

What is the expected behavior?
I can select/inspect an element on the iframe-loaded extension page.

What went wrong?
I can't select/inspect an element on the iframe-loaded extension page.

Did this work before? Yes 54.0.2840.71 (may work for later)

Chrome version: 64.0.3282.186  Channel: stable
OS Version: OS X 10.12.6
Flash Version:
 
background.js
231 bytes View Download
contentscript.js
201 bytes View Download
iframe.html
390 bytes View Download
manifest.json
509 bytes View Download
Labels: Needs-Triage-M64
Labels: Needs-Bisect
Cc: sindhu.chelamcherla@chromium.org
Labels: -Pri-2 -Needs-Bisect hasbisect-per-revision M-64 FoundIn-64 Target-64 OS-Linux OS-Windows Pri-1
Owner: sadrul@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 64.0.3282.186 using Mac 10.13.3,Windows 10 and Ubuntu 14.04 but not reproducible on latest beta 65.0.3325.88 and latest canary 66.0.3355.0. Hence providing reverse bisect info.

Last Bad Build: 65.0.3315.0
First Good Build: 65.0.3316.0

You are probably looking for a change made after 527631 (known good), but no later than 527632 (first known bad).
CHANGELOG URL:  
 https://chromium.googlesource.com/chromium/src/+log/218704dd24fb77692c7215e198b4672bd64ea531..bc55716b7ce8d4a19eea2b4b9d62bf4ad72e7a6b

Probably fixed by https://chromium-review.googlesource.com/848033

@sadrul: Please merge to M-64 if is safe. Adding RB-Stable for M-64. Please remove if not the case

Comment 4 by sadrul@chromium.org, Feb 27 2018

Cc: kenrb@chromium.org
That particular change unfortunately cannot be merged back to M64, because the code it changes does not exist in M64.

Comment 5 by kenrb@chromium.org, Feb 27 2018

Mergedinto: 755515
Status: Duplicate (was: Assigned)
We are a week away from M65 Stable promotion, so adding RB-Stable for M64 doesn't really make sense in any case.

This is a dupe of  issue 755515 . I mentioned there that the fix was not mergeable to M64, because it was a large and risky change to input event routing.

Sign in to add a comment