browser_dbg-iframes.js fails with same-origin frame targets
Categories
(DevTools :: Debugger, task)
Tracking
(Not tracked)
People
(Reporter: nchevobbe, Unassigned)
References
Details
(Whiteboard: dt-perf-stability-mvp)
Attachments
(2 obsolete files)
Not sure what's happening yet, but with an initial patch for Bug 1685500, the test is failing
Comment 1•3 years ago
|
||
This fails because of the isInitialDocument
check.
It passes if I apply:
diff --git a/devtools/server/connectors/js-window-actor/DevToolsFrameChild.jsm b/devtools/server/connectors/js-window-actor/DevToolsFrameChild.jsm
index 336ba36ef4d8d..25e16b4106091 100644
--- a/devtools/server/connectors/js-window-actor/DevToolsFrameChild.jsm
+++ b/devtools/server/connectors/js-window-actor/DevToolsFrameChild.jsm
@@ -64,7 +64,7 @@ function shouldNotifyWindowGlobal(
// and isn't expected by the spec.
// Note that `window.print` and print preview are using `window.open` and are going throught this.
if (window.document.isInitialDocument) {
- return false;
+// return false;
}
// If we are focusing only on a sub-tree of Browsing Element,
I believe we should get rid of this ignore code. To the cost of creating extra targets which are immediatly destroyed.
It may become a performance issue and break tests/features by throwing such short lived targets.
We might still want to filter out OOP initial document, but I don't think there is any JS attribute to detect them.
Here is a try run to see what tests think about doing this:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=925a6342573a4dc6fdeaa2f1b7d8454d02c83f5a
If try is green, it would be worth looking at DAMP.
Comment 2•3 years ago
|
||
If accepting initial documents is an issue, we might accept them only for non-top-level documents...
Comment 3•3 years ago
|
||
Comment 4•3 years ago
|
||
When loading a iframe in the same origin/process, we end up in a same case.
A first "initial" about:blank document is created to bootstrap the iframe.
Related to that a DOMWindowCreated event is fired and its document.isInitialDocument is true.
If no URL is set on the iframe, it stops there and we won't create any target for this special document.
(As we ignore DOMWindowCreated events when document.isInitialDocument is true)
Then, if an URL is set on the iframe, we wouldn't create any new WindowGlobal,
instead we will reuse the about:blank's document's one.
It means that there won't be any new DOMWindowCreated event.
Fortunately, there is a DOMDocElementInserted fired, which we can listen here.
We can then instantiate a target actor and that, only if no target was previously created
by a previous DOMWindowCreated. In all other cases, we would receive a DOMWindowCreated
with document.isInitialDocument set to false.
Comment 5•3 years ago
|
||
Bug 1730154 will fix this test failure and has a better description of the underlying issue.
I'll move my patch there.
Comment 6•3 years ago
|
||
Comment on attachment 9245882 [details]
Bug 1730171 - [devtools] Create targets for same-process iframe documents.
Revision D128456 was moved to bug 1730154. Setting attachment 9245882 [details] to obsolete.
Updated•3 years ago
|
Description
•