Steps to Reproduce:

1. Enabled Fission
2. Open https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
3. Print
4. Select Save to PDF and More settings > Select Page size to US Letter
5. Repeatedly click > page-nation button
   -- Just before displaying the 9th page, the entire Firefox window will flash.
6. Repeatedly click < page-nation button
   -- Just before displaying the 8th page, the entire Firefox window will flash.
7. When the problem occurs at step5 or step6, mouse move to outside of Firefox window
   --- The entire Firefox window will blank.

Actual Results:
The entire Firefox window will flash and blank.
Screencast: https://youtu.be/J3f5w4CKwj4

Expected Results:
This problem should not occur.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=487c3eb6a0cdc989e28268562d1d753671fcdee6&tochange=c67cec98bf16173efd69cff2f12d1ffbb09c907f

Glenn, this bug looks like a regression from your spatial tree changes in bug 1734740.

I can't reproduce this locally.

From the screencast, it looks like maybe the GPU process panics and restarts on Windows.

Although I'm testing on Linux, I would expect a bug in the reported regression would probably panic on all platforms, since the WR changes in that patch are all platform agnostic.

I can update my Windows dev machine and try to repro there, but it will take a while to do that. Has anyone else been able to repro locally, and/or could check if it's Windows-specific?

I can repro locally on an up-to-date Windows (so maybe Windows-specific somehow?). Can try Linux tomorrow. Indeed the GPU process crashes, here are some crash reports:

• https://crash-stats.mozilla.org/report/index/9c9bd02e-9bb3-40ec-a9d0-4f5f60211128
• https://crash-stats.mozilla.org/report/index/827d2f5f-0b50-4c91-bc18-b927f0211128
• https://crash-stats.mozilla.org/report/index/23c23060-db85-4327-9f87-ac3bd0211128

Unfortunately it seems like the panic message isn't saved in the crash report? That's unfortunate, I don't know how the line of code linked from the crash report can really panic... Glenn does the above help?

I can't repro on a local Windows debug build though...

The referenced line in those crash reports just seems to be a single line function that pushs an id into a vec, doesn't seem like it could panic, if I'm looking at the right location.

I wonder if there might be something wrong with rust backtraces at the moment, there is another bug I was looking at this morning which also seems to panic somewhere that doesn't make sense (and also doesn't report the panic string).

I'm currently updating my windows env, will see if I can repro locally then.

I can reproduce locally on a windows VM, so it must be platform specific (maybe the shape of the spatial tree on this page is different enough to reproduce on windows).

It might be similar underlying cause to https://bugzilla.mozilla.org/show_bug.cgi?id=1736069, which we suspect might be printing related. I'll see what I can find today.

In certain situations (such as a print preview dialog, with fission
enabled, where an iframe spans a page), the display list contains
a reference to the same iframe multiple times. In the cases I
observed, the display item had the same parent spatial node, so
the iframes would have been drawn on top of each other, which
seems like a bug.

Since WR relies on an iframe only being referenced once (for unique
spatial key reasons) detect this case and skip subsequent references
to iframes during scene building.

Long term, we should aim to change Gecko to not supply display lists
with duplicated iframe references, if possible. If we get any bug
reports with visual artifacts, we can consider adding support for
this to WR itself (we could namespace the spatial key IDs by iframe
instance, or parent spatial nodex index, for example).

Note to self: we will definitely want to get this uplifted to beta.

Load this testcase and try to print (ie show the print preview).

During printing (or print preview) Gecko builds display lists that have duplicate content. This is done to improve fragmentation when a web page cannot be easily paginated at layout level. This was added in bug 1640197.

The way it roughly works is that when we detect that page content would go beyond the bounds of the current page, we draw the overflowing content at the beginning of the next page, and push the actual next page content down.

I filed bug 1743533 for the issue of not drawing the iframe contents in this testcase that still remains after the patch in this bug fixes the crash.

Updated the patch in https://phabricator.services.mozilla.com/D132318, I'm hopeful it will address this issue and also 1743533.

In certain situations (such as a print preview dialog, with fission
enabled, where an iframe spans a page), the display list contains
a reference to the same iframe multiple times.

Handle this in WR by namespacing the spatial id (via a stack as
iframes are traversed) and uid (by iframe pipeline instance id).

This is more of a band-aid fix than a proper fix - we need to
rethink how we handle spatial mapping properly with iframe
instances.

https://hg.mozilla.org/mozilla-central/rev/0060a40e3c6a

Glenn, Firefox 95 is shipping to Release tomorrow. It's too late to uplift this crash fix to Beta 95. Would we want to uplift this fix to a (hypothetical) 95.0.1 dot release?

I think it's probably worth uplifting it, if it's going to be easy to do (not sure how I request that for a dot release though). It's fairly low volume, the release managers didn't seem too concerned by it, but maybe check in with them to see if they'd want to take it?

The fix itself is a slightly subtle change, but so long as it stays in nightly for a couple of days it should be safe to uplift.

In case there is a dot release.

Reproduced the issue with Win 10x64 Fx 96.0a1(2021-11-26).
Verified the issue is fixed with Win 10x54 Nightly 97.0a1 and Fx 96.0b4.