1697790 - Print Preview - not rendering image

Status: RESOLVED DUPLICATE of bug 1697963

(Core :: Print Preview, defect)

Description

[Frederick]

Attachment: print-bug.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36

Steps to reproduce:

We display documents in our website, and allow to print those documents.
We do this by downloading one image per page, and add an <img ...> tag inside a parent "<div class='print'>" tag.
We then automatically call window.print().

remark:
We have a dedicated @media print { ... } section that hides everything, except the "print" div. And in the browser we hide the print div.

Actual results:

The print preview is opened, but does not show the content of all the images.
Most of the time the first image is not rendered.
If we have multiple pages, it is possible that scrolling down and up again will resolve most pages. (But never all.)

When you then accept the print settings, all images are printed. Also those that are not visible in the print preview.

Expected results:

All images should be visible in the print preview.
Note that we explicitly wait for the image load event before we start the print process. So the information is certainly available.

Comment 1

[Frederick]

The attached file "print-bug.html" allows to reproduce the problem.
Just load it, click "Add Pages", then click the "Print manual" button.
Both should result in the same print preview.
Use Ctrl+F5 to refresh the page and try again.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Print Preview' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Thanks a lot for reporting this.

So, the example seems to work consistently for me on Nightly, at least. Is there any chance that you could attach your about:support information? Thanks.

Comment 4

[Frederick]

Attachment: about:support

Sure, attached!

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Ok, great, I'll try to repro this on windows release (I'm on Linux r/n).

Also, two other questions:

• When you reproduce the bug, if you change any print setting, like e.g. page orientation, does the missing image start displaying?
• Does this reproduce on a build from https://nightly.mozilla.org? (You can install it alongside regular Firefox, so installing it is not a lossy operation).

Thanks!

Comment 6

[Frederick]

Hi, it is still reproducible on the nightly build.
Changing print settings does not resolve the problem.
Kind regards, Frederick

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Ok, thanks! ni?ing myself to not forget to check this on windows.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Ahá, so I can't repro this on windows either, but I can reproduce in windows if I start changing the print settings after showing the preview for the first time, so that gives me something to investigate. Thank you!

Comment 9

[Emilio Cobos Álvarez (:emilio)]

This reproduces with the old print preview, so it doesn't seem like a recent regression. It also reproduces on a year-old build which doesn't include bug 1648064 (where I refactored how images worked in print / print preview...).

Comment 10

[Frederick]

If I'm not mistaken there was recently a change in FF that enabled the preview?
And maybe the reason that we had no problems in the past is because we did not use this feature by default?
Just thinking out loud ...

see: https://winaero.com/firefox-81-receives-a-new-print-preview-dialog/
and: https://techdows.com/2021/02/disable-new-print-ui-in-firefox-86.html

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Yes, that's right. But firefox has always had a "Print Preview" in "File > Print Preview", and I can reproduce with that.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Ok, I took a look and I think I see what's going wrong. Can you confirm that if you go to about:config, and change gfx.webrender.force-disabled=true, and restart, then you don't see the issue?

Comment 13

[Emilio Cobos Álvarez (:emilio)]

So, here's what's going on. If WebRender is enabled, we bail out from here because FrozenImage::GetImageContainerAtSize returns NOT_SUPPORTED.

So that's fine, and then we enter the fallback path. But if the image is not decoded yet (NOT_READY) then we rely on UpdateImageGeometry to record that the image was, in fact, not ready.

But the geometry there is null, because it's a WebRenderFallbackData rather than an image data, and that doesn't seem to override GetGeometry, so we get null.

Patch incoming.

Comment 14

[Frederick]

Hi, it's better but does not completely solve the problem.

It still shows an empty page; but when you scroll down and up again the page becomes visible.
Of course we still need to scroll, and this trick does not work if you have only one page.

PS: the scroll trick already worked "partially" previously, but there always was at least one page that was not rendered.
And with this config change all pages are rendered.

Hope this helps.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

err, I accidentally posted these patches in bug 1697963, so will repurpose that one. This should be fixed in tomorrow's nightly or the one after, depending on when the merges happen.

Comment 16

[Frederick]

I have tested this on the new nightly build, and it works.
Thanks a lot!

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Great, thanks for testing :)