Intermittent WPT Fission browsers/windows/iframe-cross-origin-print.sub.html with a blank remote iframe
Categories
(Core :: DOM: Content Processes, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox92 | --- | fixed |
People
(Reporter: cpeterson, Assigned: hiro)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
[iframe-cross-origin-print.sub.html]
disabled:
if fission: https://bugzilla.mozilla.org/show_bug.cgi?id=1574508
This test was disabled by bug 1662336 because of Marionette bug 1574508, which has since been resolved as WFM. Maybe we can re-enable this test now?
Reporter | ||
Comment 1•4 years ago
|
||
Moving to the Core::DOM: Content Processes component because this is not a Marionette bug.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
I tried locally but interestingly it's still broken. As such we cannot re-enable this test yet. I reopened bug 1574508.
Comment 3•4 years ago
|
||
I tried to re-enable this based on the fix from Bug 1574508, but we now have a real reftest failure, as in the screenshots don't match. The one we take with the page using remote frames looks zoomed out compared to the real one. We get the same issue locally and on try, so it doesn't seem to be a DPI issue.
Test page: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/browsers/windows/iframe-cross-origin-print.sub.html
Reference page: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/browsers/windows/iframe-nested-print-ref.html
jwatt: Considering that this is a print test, jgraham suggested getting in touch with you about this. Do you know what might be causing this?
Comment 4•4 years ago
|
||
Comment 5•4 years ago
|
||
Comment 6•4 years ago
|
||
I just tried locally to save as PDF a random page with a remote frame (http://janodvarko.cz/tests/fission/case10/index.html) from the current Nightly, and I see the same issue as on the reftest. The remote frame is zoomed out in the fission scenario, and has the correct size in the non-fission scenario.
This might be a known print issue, but I couldn't find an existing bug. Let me know if I should file one. In the meantime I think the only thing we can do for this reftest is to mark it as expected to FAIL with fission.
Comment 7•4 years ago
|
||
Note: we are updating the metadata for this test to fail on fission in bug 1574508.
Comment 8•4 years ago
|
||
Julian, mind updating the bug's summary to include the new kind of failure? Something like:
Perma wpt Fission browsers/windows/iframe-cross-origin-print.sub.html | %reason%
Comment 9•4 years ago
|
||
Oh, sorry for the accidental update. It was not wanted. So we still miss the exact failure message.
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Clearing the ni? Filed a dedicated bug for the root issue: Bug 1699837
Comment 11•3 years ago
|
||
Julian, can you please retest and check if this can be re-enabled now?
Comment 12•3 years ago
|
||
This is still failing, although now the fission print is fully blank instead of being zoomed out.
Can't reproduce yet on an isolated test case, investigating.
Comment 13•3 years ago
|
||
Reproduced in https://bug1695806-root.glitch.me/
Print preview for this page is blank when fission is on. Root document is:
<!doctype html>
<style>
body { margin: 0 }
</style>
<iframe frameborder=0 scrolling=no src="https://bug1695806-crossframe.glitch.me/"></iframe>
remote frame is
<!doctype html>
<iframe scrolling=no frameborder=0 srcdoc='PASS'></iframe>
Checking if this is related to the fix from Bug 1699837 or to something else.
Comment 15•3 years ago
|
||
Thank you, Julian, for re-testing it and for figuring out the new STR and filing the bug. :)
This new failure sounds like a corner case so I'm marking it down for M8. Please let me know if you disagree.
Comment 16•3 years ago
|
||
Sounds good to me, thanks for the update!
Updated•3 years ago
|
Comment 17•3 years ago
|
||
I can see two remaining issues:
- on try, it seems that now the test document will intermittently lead to a blank print when fission is enabled
- locally, the print preview is blurry when Fission is enabled (I can't actually reproduce the blank print from try)
Assignee | ||
Comment 18•3 years ago
|
||
I was running into this issue, and looked into detail what's going on there. So, an apparent problem is when we initiate CrossProcessPaint::Start, the oop iframe's document is still "about:blank", and then it switches to the proper iframe document, thus we fail to get the WindowGlobalParent for the iframe's document, or fail to get the fragment.
CCing Matt and Nika.
Comment 19•3 years ago
|
||
So is this just a race, where we're trying to take a screenshot/print the page, before we've reached a fully stable state?
The CrossProcessPaint doesn't try too hard to deal with this problem in general, just detects that things have changed during the async process of collecting recordings, and fails if so. It's possible that we could instead produce a rendering with whatever results we did get, but I feel that makes it harder to know if you got what you wanted.
Assignee | ||
Comment 20•3 years ago
|
||
I've poked more detail. Actually it's a race. The race is we start sending DrawSnapshot request before we finished cloning the corresponding document in an out of process. So what we need to do is; defer sending the Drawsnapshot request until we finished cloning. That means;
- Make CloneDocumentTreeIntoSelf return a MozPromise
- When we received RecvCloneDocumentTreeInto, set a flag to (Canonical)BrowsingContext to represent the remote document is currently cloning, the reason of using (Canonical)BrowsingContext is it's persisted
- When we try to queue the paint request for an OOP iframe, check the flag and if the document is being cloned, defer the request later once after the clone has finished
- To tell the clone finish, add a callback function to the CanonicalBrowsingContext and the CanonicalBrowsingContext invokes the callback when the CloneDocumentTreeIntoSelf's MozPromis is resolved or rejected
With these setups, the test works fine, I've never seen the failure locally on my Linux box and try runs.
Note that I guess this race also can happen on taking normal snapshots (images), for example, if the target content has an in-process iframe and the iframe tried to load a cross-origin site just before taking a snapshot. I am not sure what happens in the case, I think it's very rare. If it happened we could reuse some pieces of these setup.
Assignee | ||
Comment 21•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 22•3 years ago
|
||
Depends on D119949
Updated•3 years ago
|
Comment 23•3 years ago
|
||
Comment 24•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3c5186df3677
https://hg.mozilla.org/mozilla-central/rev/c2741585119b
Description
•