[Affected versions]:
Nightly 68.0a1

[Affected platforms]:
Platforms: WINDOWS10

[Steps to reproduce]:

1)Open this site link in firefox: http://upload.wikimedia.org/wikipedia/commons/2/2c/Rotating_earth_%28large%29.gif
2)Click Option menu, then Print the site to an actual printer.
3)Image preview screen appears but there is no image.

Expected result:
The gif image should appear on print preview

Actual Results:
The gif image is not showing up on print preview

Results from the Mozregression:
We also tried getting a regression range for this issue but we kept getting some build errors and this is the best we could do, if any of you guys can take a look and see what the culprit might be

Here are the results from the Mozregression:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=68941a0829dc729a979b25061c258ae51859a5a4&tochange=37103bfa3dca5149f414cc6265d24fd752a4385f

In that range, this looks particularly suspicious, for a "something's not showing up" bug like this one:

Bug 1523823. Enable WebRender by default on modern (CIK, VI, GFX9) desktop AMD hardware. r=kats

Could you check about:support to see if you have WebRender enabled, and (if so) test whether this reproduces if you turn it off? (I think that setting about:config gfx.webrender.force-disabled = true will force it off, though you may have to restart Nightly after making that change.)

Hi there!
Here is the data

On about:Support > available by user: Qualified enabled by pref
I went to about:config and searched for gfx.webrender.force-disabled (it was set as false)
The image on print preview did not show up

Then on about:config , gfx.webrender.force-disabled i changed it to TRUE
Closed and launched firefox again and i was able to see the image on print preview.
on about:Support > disabled by user: User force-disabled WR

regards

Then on about:config , gfx.webrender.force-disabled i changed it to TRUE
Closed and launched firefox again and i was able to see the image on print preview.

Thanks! It sounds like the bug goes away when you turn off WebRender then. So, this is a bug that is specific to our WebRender backend.

--> reclassifying accordingly.

Andrew can you take a look?

Tested it on Windows10:

Firefox Release 66.0.5 : It is working
Firefox Beta : 67.0 : It is working
Firefox Nigtly 68.0a1: It does not work.

This is not a recent regression. I could reproduce on very old WebRender builds. It appears that if the static image is already in the cache, it will render correctly. You can reproduce this by opening the print preview, noting its failure, closing it, reopening it and noting its success. So it looks like a notification is being missed somewhere. Normally you already have the images already decoded because you see them on screen, but a first frame only decoding is kicked off for animated images after the fact.

With WebRender, we had observed that the print preview for animated
images was not displaying correctly. It should display the first frame
but it was showing nothing the first time the preview was opened. Once
the decoded image was available in the cache, it would display
correctly if the preview was reloaded.

The StartDecoding and RequestDecode variants always requested
FRAME_CURRENT for animated images. They should use FRAME_FIRST for
static requests / FrozenImage. Correcting this fixes the print preview.

https://hg.mozilla.org/mozilla-central/rev/a479292cb15c

P2, only affects Webrender users and does not affect browsing, given the size of the patch and the current impact, I am marking it as wontfix for 67.

Comment on attachment 9066491 [details]
Bug 1550523 - Ensure that decoding methods for frozen images request the correct frame.

Beta/Release Uplift Approval Request

• User impact if declined: Print preview may show incorrectly if there is an animated image with WebRender.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch adds a parameter to allow a caller to select what frame we would like to initiate decoding for, the first frame (for print preview) or the current frame (for drawing). We change this only on the FrozenImage code path, which is primarily used just for printing. Even if the wrong frame was displayed, right now it doesn't display anything, so it is unlikely to cause a further regression.
• String changes made/needed: None

I verified this now works on Linux and Windows nightly, when previously it would fail for me.

Comment on attachment 9066491 [details]
Bug 1550523 - Ensure that decoding methods for frozen images request the correct frame.

print preview fix for WR; approved for beta68

https://hg.mozilla.org/releases/mozilla-beta/rev/3e3ebfd84955

I am not able to reproduce this issue. I tried the steps from comment 0 and from comment 2, but with no success of reproducing the bug.
Can you please give me some additional info about how you managed to reproduce it?
Thank you.

Please force-enable WebRender by gfx.webrender.all and restart Firefox if your device is not qualified yet.

(Pablo from comment #0)

1)Open this site link in firefox: http://upload.wikimedia.org/wikipedia/commons/2/2c/Rotating_earth_%28large%29.gif
2)Click Option menu, then Print the site to an actual printer.

a) Main menu > Print
b) <Alt> > File > Print Preview

3)Image preview screen appears but there is no image.

Verified fixed:

• Nightly 69: Win10/GTX1060, Debian Testing/Macbook Pro
• Beta 68.0b5: Win10/GTX1060

Wontfix:

• Stable 67

I managed to reproduce the issue using an older version of Nightly (2019-05-09) on Windows 10 x64.
I retested everything using Nightly 69.0a1 and Firefox 68.0b5 on Windows 10 x64 and Ubuntu 18.04 x64 and the bug is not reproducing anymore.