Inspector no longer displays elements in iframe when console icon is clicked
Categories
(DevTools :: Console, defect, P1)
Tracking
(firefox-esr68 unaffected, firefox70 unaffected, firefox71+ fixed, firefox72 fixed)
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox70 | --- | unaffected |
| firefox71 | + | fixed |
| firefox72 | --- | fixed |
People
(Reporter: v+mozbug, Assigned: nchevobbe)
References
Details
(Keywords: regression)
Attachments
(5 files)
ss_20191101_131043_946.jpg
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Steps to reproduce:
I have a multi-frame document. It is far to complex to include here, but it will likely take some work to make a test case.
As part of the debug eenvironment for this document, I wrote a function that takes a selector and an iframe as a parameter, and runs querySelector on document in the iframe, and calls console.log with the result. This gives me a display on the console that shows a bit of info about the element, and a targe icon at the end which can be clicked to cause Inspector to display that element. This has been extremely helpful in FF branches earlier than 71 (including 70).
Actual results:
In 71 branch, clicking the target icon takes me to the <body> element of the outer document, rather than showing me the selected element within the iframe.
Expected results:
I would really, really, really like it to still take me to the selected element within the iframe, because navigating the inspector to the inside of an iframe takes many, many clicks just to get to the iframe, and then more to get inisde that iframe's document structure.
|
Reporter | |
Comment 1•5 years ago
|
||
I'm hoping this is something that a DevTools developer can quickly find by inspection, but I'll make a test case if not.
Alternately, if there is another way to achieve the goal here, of quickly navigating the inspector to an element inside an iframe, I'd like to know about it.
Further, there is no CORS issue here: same document, same code works fine in 70 Branch (and earlier), but fails in 71 branch.
|
||
Comment 2•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
|
Reporter | |
Comment 3•5 years ago
|
||
|
|
Reporter | |
Comment 4•5 years ago
|
||
|
|
Reporter | |
Comment 5•5 years ago
|
||
|
|
Reporter | |
Comment 6•5 years ago
|
||
|
|
Reporter | |
Comment 7•5 years ago
|
||
Made a test case. Put the two HTML files in the same directory on a server. Load testinspector.html in the browser.
If the browser is 70 branch or below, when you open the DevTools console and click the icon from the console.log startement, you get the first screenshot. Useful.
If the browser is 71 branch, when you open the DevTools console and click the icon from the console.log startement, you get the second screenshot. Not useful.
This is an extremely time-wasting regression in the use of DevTools: In a well-populated document in the iframe, navigating to the iframe, and then individually opening up all the nesting levels (and searching at each level for what you which one you want to open) is extremely time-wasting.
Being able to use querySelector in a helper function and select a particular item to log to the console, and then being able to click the icon from the log statement and go directly to the element of interest in the inspector is extremely powerful... but is broken in 71 branch.
|
|
Reporter | |
Comment 8•5 years ago
|
||
Another probably related weirdness.... my actual documents have a bunch of CSS grid inside the iframe... when I load the parent document and it loads the child into the iframe, all those grids appear in the 3rd column of the Inspector, if I open the grids list.
Next to each grid is the little icon to take you there: it works, at first, sometimes. And other times not. But if I do much after the load (such as run a little javascript from the console that tweaks the child document), then the icon no longer works, but goes to the parent document only.
|
|
||
Comment 9•5 years ago
|
||
The priority flag is not set for this bug.
:gl, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Comment 10•5 years ago
|
||
Forwarding this over to pbro since I am on Fenix atm.
|
|
Reporter | |
Comment 11•5 years ago
|
||
OH NO! Inspector now no longer shows the grids that are inside a frame in the grid list mentioned in Comment 8. That was a sometimes usable workaround. But now they aren't listed.
If this is some sort of purge of information from nested browsing contexts, there needs to be a way to quickly select a nested browsing context, and the icons for DOM elements displayed on the console needs to determine what browsing context the element is in, and display that nested browsing context, (and the CSS custom properties from its parents that leak through), instead of starting at the top browsing context and stopping because the DOM element is not in that browsing context.
|
||
Comment 12•5 years ago
|
||
Thanks for filing Glenn, sorry about this regression.
I ran the mozregression tool to pinpoint what broke this, and ended up with this regression window:
So it could be any of these 3 bugs:
- Bug 1577783 - Use inspectorFront's getNodeFrontFromNodeGrip function in WebConsole's openNodeInInspector
- Bug 1587701 - Use toolbox's getNodeFrontFromNodeGrip in highlight method
- Bug 1586201 - Add a function to get a nodeFront from a ContentDomReference
Surprisingly, the test case does work in nightly (Fx 72), so the problem got fixed again. So I ran the tool again to find out when the bug got fixed and ended up with this window:
So this bug fixed it apparently: Bug 1578745 - Introduce a preference to enable fission frame inspection in DevTools.
Let's track release 71 on this bug to make sure it stays on our radars before 71 moves to release. This is a pretty bad regression that we should fix asap I think.
Nicolas: any idea about whether the fix for bug 1578745 should be uplifted here, or if a custom fix is required for beta only?
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 13•5 years ago
|
||
Nicolas: any idea about whether the fix for bug 1578745 should be uplifted here, or if a custom fix is required for beta only?
I think we can uplift this bug as it fixes the issue + the preference is set to false by default.
|
|
Assignee | |
Comment 14•5 years ago
|
||
It would also be nice to have a test for this failure, so we don't cause further harm.
|
|
Assignee | |
Comment 15•5 years ago
|
||
|
|
Assignee | |
Comment 16•5 years ago
|
||
The attached patch adds a test that checks that an element coming from a cross origin iframe can be highlighted and selected in the inspector.
I was able to make the test fail by making the following change in the inspector front, which reverts the part of bug 1578745 that fixed the issue:
diff --git a/devtools/shared/fronts/inspector.js b/devtools/shared/fronts/inspector.js
--- a/devtools/shared/fronts/inspector.js
+++ b/devtools/shared/fronts/inspector.js
@@ -203,7 +203,7 @@ class InspectorFront extends FrontClassW
async getNodeFrontFromNodeGrip(grip) {
const gripHasContentDomReference = "contentDomReference" in grip;
- if (!this.isContentFissionEnabled || !gripHasContentDomReference) {
+ if (!gripHasContentDomReference) {
// Backward compatibility ( < Firefox 71):
// If the grip does not have a contentDomReference, we can't know in which browsing
// context id the node lives. We fall back on gripToNodeFront that might retrieve
The uplift was requested on Bug 1578745, so maybe we can re-purpose this bug to only land the test, which will be uplifted as well to ensure everything is okay in 71.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 17•5 years ago
|
||
Pushed by nchevobbe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/21e687c1e793 Add a test case checking cross-origin iframe elements logged in console can be highlighted. r=pbro.
|
|
||
Comment 18•5 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
|
||
Comment 19•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
|
||
Comment 20•5 years ago
|
||
| bugherder uplift | ||
Description
•