1650176 - Printing a video should capture the current playing frame

Status: NEW

(Core :: Audio/Video, defect, P3)

Description

[Olli Pettay [:smaug][[e-mail]]]

I think video printing has been broken for a quite some time.

Initially the code was like https://hg.mozilla.org/mozilla-central/annotate/180966423a3c8f87a1af9ff894a4c22d5d35e106/content/html/content/src/nsHTMLMediaElement.cpp#l2017 to get something to print.

https://hg.mozilla.org/mozilla-central/rev/1a4c3d1d0c57cd32f1f8f12b159c736fba980cdb#l3.46 made some changes to the painting.

Then way later some relevant code was removed
https://hg.mozilla.org/mozilla-central/rev/e2a8de576daf9edd9138da4d6deb5c5b9228d42d#l2.34
So something between those latter two broke printing, I believe.

STR:
Load: https://www.w3schools.com/html/mov_bbb.mp4
Enter print preview. One should see the current frame of the video.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

( Not sure blocking bug 1601429 is the right dependency )

Comment 2

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

As someone unfamiliar with how printing is handled, I was surprised to see media elements maintain their own surface to facilitate this. Is that still expected/needed? My naive thought would be we just blit from somewhere in the GFX pipeline.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

The old behavior was that a frame was captured and used in static clones of the original document (printing and print preview create a static clone of the original document). That way the video can keep progressing in the original tab, but print preview tab doesn't get updated.

Comment 4

[Mats Palmgren (inactive)]

Restoring the old behavior would be nice, but it's not a major issue IMO. Chrome have the same behavior we have currently.