Closed Bug 1695806 Opened 3 years ago Closed 3 years ago

Intermittent WPT Fission browsers/windows/iframe-cross-origin-print.sub.html with a blank remote iframe

Categories

(Core :: DOM: Content Processes, defect, P3)

defect

Tracking

()

RESOLVED FIXED
92 Branch
Fission Milestone M8
Tracking Status
firefox92 --- fixed

People

(Reporter: cpeterson, Assigned: hiro)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

https://searchfox.org/mozilla-central/rev/26330a08b1f9d06938faa0aa5e0f8c7a58064aa2/testing/web-platform/meta/html/browsers/windows/iframe-cross-origin-print.sub.html.ini#3

[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?

Moving to the Core::DOM: Content Processes component because this is not a Marionette bug.

Component: Marionette → DOM: Content Processes
Product: Testing → Core
Version: Default → unspecified
No longer blocks: 1574508
Depends on: 1574508

I tried locally but interestingly it's still broken. As such we cannot re-enable this test yet. I reopened bug 1574508.

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.

See https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/O7cHlpaATYGRKXsOaYk_5w/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

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?

Flags: needinfo?(jwatt)

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.

Note: we are updating the metadata for this test to fail on fission in bug 1574508.

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%

Flags: needinfo?(jdescottes)
Summary: Re-enable WPT browsers/windows/iframe-cross-origin-print.sub.html for Fission → Perma WPT Fission browsers/windows/iframe-cross-origin-print.sub.html

Oh, sorry for the accidental update. It was not wanted. So we still miss the exact failure message.

Flags: needinfo?(jdescottes)
Summary: Perma WPT Fission browsers/windows/iframe-cross-origin-print.sub.html → Perma WPT Fission browsers/windows/iframe-cross-origin-print.sub.html | FAIL: remote frame is zoomed out when printed
Depends on: 1699837

Clearing the ni? Filed a dedicated bug for the root issue: Bug 1699837

Flags: needinfo?(jwatt)

Julian, can you please retest and check if this can be re-enabled now?

Flags: needinfo?(jdescottes)

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.

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.

Flags: needinfo?(jdescottes)

Filed Bug 1716537 for the new STRs.

Depends on: 1716537

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.

Fission Milestone: M7a → M8

Sounds good to me, thanks for the update!

Summary: Perma WPT Fission browsers/windows/iframe-cross-origin-print.sub.html | FAIL: remote frame is zoomed out when printed → Intermittent WPT Fission browsers/windows/iframe-cross-origin-print.sub.html with a blank remote iframe

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)
Depends on: 1720152

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.

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.

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;

  1. Make CloneDocumentTreeIntoSelf return a MozPromise
  2. 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
  3. 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
  4. 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: nobody → hikezoe.birchill
Status: NEW → ASSIGNED
Blocks: 1700245
Attachment #9231290 - Attachment description: Bug 1695806 - Defer sending a snapshot reqeust for remote process iframe until cloning the iframe document finished. r?mattwoodrow → Bug 1695806 - Defer sending a snapshot reqeust for remote process iframe until cloning the iframe document finished. r?mattwoodrow,nika!
Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3c5186df3677
Make CloneDocumentTreeIntoSelf return a MozPromise to be able to wait for its completion. r=mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/c2741585119b
Defer sending a snapshot reqeust for remote process iframe until cloning the iframe document finished. r=mattwoodrow,nika
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: