1849555 - Glitches in print preview while rapidly clicking the "Print backgrounds" option

Status: RESOLVED WONTFIX

(Core :: Web Painting, defect)

Description

[Ciprian Georgiu, Desktop QA]

Found in

• Beta 117.0b9

Affected versions

• latest Nightly 118.0a1
• latest Beta 117.0b9
• RC 116.0.3

Tested platforms

• Affected platforms: Win 11 x64, macOS 11, Ubuntu 22.04 x64

Steps to reproduce

1. Launch Firefox.
2. Navigate to https://mmec.ca/public-calendar/.
3. Open the print preview.
4. From the "More settings" option, rapidly click on the "Print headers and footers" or " Print backgrounds" checkboxes.

Expected result

• No glitches can be observed in the print preview.

Actual result

• Glitches can be observed in the print preview. A pink background flashes on the calendars that are displayed in the print preview.

Regression range

• changeset: 06c7b4e2d14be1ee8050d6c1eb1ab1bab19ac3c2
• pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1a4d9850780709a65b7a090bfbd8eb48f209b3a7&tochange=06c7b4e2d14be1ee8050d6c1eb1ab1bab19ac3c2

I'm not sure which bug is the culprit looking at the changelog, maybe Bug 1745262. Unfortunately, I cannot go further with the bisection, I'm getting an error in mozregression saying that it can't find any other builds.

Additional notes

• Please observe the screencast with the issue.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Mark, any thoughts on this?

Comment 2

[Mark Striemer [:mstriemer]]

Attachment: Screen Recording 2023-08-29 at 11.05.06.mov

I don't know what would cause this, but the page appears to have the same behaviour which makes me think the issue is on the site (sort of seems like the colour indicates a loading state?)

Comment 3

[Mark Striemer [:mstriemer]]

Attachment: image.png

The page also has a print disclaimer in the HOVER ... text that it might not print properly

Comment 4

[Mark Striemer [:mstriemer]]

Attachment: image.png

And Chrome is totally busted with backgrounds on.

Really seems like something odd on the site, dunno if it should be fixed on our end but the print preview does accurately reflect the site and looks like it would print fine in Firefox

Comment 5

[Mark Striemer [:mstriemer]]

Attachment: image.png

And Safari (which is suggested for some reason) with backgrounds on

Looks like we're the only browser that can print this page, seems like a WONTFIX to me

Comment 6

[Daniel Holbert [:dholbert]]

Regression range

• changeset: 06c7b4e2d14be1ee8050d6c1eb1ab1bab19ac3c2
• pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1a4d9850780709a65b7a090bfbd8eb48f209b3a7&tochange=06c7b4e2d14be1ee8050d6c1eb1ab1bab19ac3c2

I'm not sure which bug is the culprit looking at the changelog

I think the culprit in that push log was bug 1732358, which enabled fission by default on Nightly.

What's happening here is: with fission enabled, we're now painting the iframe's contents (the calendar) asynchronously from the rest of the document, since it's rendered in a separate process. The flash of pink is the background of the element in the outer document that the iframe is covering up. And the iframe itself is transparent, so until we have its actual content (from Google Calendar) to render, then the pink content from the outer document shows up. In other words: when we repaint the document, we don't necessarily have the iframe content available to be painted right at the same time as the rest of the outer document, so you may see whatever is "covered up" by the iframe for a period of time.

So this is essentially just an instance of Fission causing iframe contents to be rendered asynchronously, which is noticeable but to-be-expected.

I'm reclassifying as Web Painting, and calling it WONTFIX since I think this is expected-behavior-with-fission.