Closed Bug 734406 Opened 8 years ago Closed 8 years ago
<canvas> elements no longer print (or preview)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a2) Gecko/20120309 Firefox/12.0a2 Build ID: 20120309042010 Steps to reproduce: Visit any of the following pages, and perform File > Print Preview, or print the page. Any of the examples here: https://developer.mozilla.org/en/Canvas_tutorial/Drawing_shapes like... https://developer.mozilla.org/samples/canvas-tutorial/2_2_canvas_moveto.html Or the following: http://www.w3schools.com/html5/html5_canvas.asp http://www.williammalone.com/articles/html5-canvas-example/downloads/simpleExample.html Actual results: The canvas elements do not appear in the resulting preview or printout. I noticed this with a site I was developing, and followed up testing sample sites. In the w3schools.com example, in the Print Preview the canvas element is replaced with the text "Your browser does not support the <canvas> element." Expected results: The canvas elements should have appeared in the Print Preview or the printout. The canvas elements appear properly in the latest Beta builds (as of today, March 9, 2012), but not in the latest Aurora or Nightly builds from today. This might be a recent regression, as I was testing printing yesterday, and I didn't have a problem, and from my recollection I was using the Nightly build. But don't quote me on that.
Regression window(m-c) Works: http://hg.mozilla.org/mozilla-central/rev/ed47a41ba26a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111222 Firefox/12.0a1 ID:20111222031055 Fails: http://hg.mozilla.org/mozilla-central/rev/c5b90ea7e475 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111222 Firefox/12.0a1 ID:20111222033040 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ed47a41ba26a&tochange=c5b90ea7e475 Regression window(m-c) Works: http://hg.mozilla.org/integration/mozilla-inbound/rev/23681bd07e4a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111221 Firefox/12.0a1 ID:20111221133437 Fails: http://hg.mozilla.org/integration/mozilla-inbound/rev/88663cf7f5c1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111221 Firefox/12.0a1 ID:20111221140437 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=23681bd07e4a&tochange=88663cf7f5c1 Suspected: 70af9bf2a4dc Boris Zbarsky — Bug 302566. Show canvas fallback content when script is disabled. r=tnikkel
Linux build also fails. http://hg.mozilla.org/mozilla-central/rev/ead9016b4102 Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120309 Firefox/13.0a1 ID:20120309062528 and http://hg.mozilla.org/releases/mozilla-aurora/rev/55ee63484487 Mozilla/5.0 (X11; Linux i686; rv:12.0a2) Gecko/20120229 Firefox/12.0a2 ID:20120229042012
OS: Windows 7 → All
I guess we're able to copy the bits of the canvas surface when we clone its DOM node, that's why it worked before. I guess if we are a print or print preview presentation we want to check the value of the scriptEnabledBeforePrintOrPreview property set here http://mxr.mozilla.org/mozilla-central/source/layout/printing/nsPrintEngine.cpp#3196
Nice catch, Chris! Thank you for testing the Aurora builds! Timothy, I think that property is set on the original document, not the clone document, so it wouldn't help. But I think I know how to fix this. Patch coming up.
I'm not sure how to write a test for this....
Attachment #604601 - Flags: review?(tnikkel)
Attachment #604601 - Flags: review?(tnikkel) → review+
Whiteboard: [need review]
Target Milestone: --- → mozilla13
Comment on attachment 604601 [details] [diff] [review] Fix printing and print preview for <canvas> by checking for script-enabled on the original document, not on the printing document. [Approval Request Comment] Regression caused by (bug #): bug 302566 User impact if declined: Printing prints <canvas> alternate content instead of the <canvas> Testing completed (on m-c, etc.): Tested on a testcase with a <canvas> and alternate content printing to a file, JS on and JS off. Risk to taking this patch (and alternatives if risky): Very low risk. This is how it should have been done in the first place. The other option is to back out bug 302566. String changes made by this patch: None.
Attachment #604601 - Flags: approval-mozilla-aurora?
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Comment on attachment 604601 [details] [diff] [review] Fix printing and print preview for <canvas> by checking for script-enabled on the original document, not on the printing document. [Triage Comment] Approved for Aurora 12. Pleas land asap.
Attachment #604601 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I'm still seeing this happen when you switch Portrait/Landcape in Print Preview. Steps to reproduce: Print preview on any of the links in the original bug report. Click Landscape or Portrait; whichever is not selected Actual results: The canvas disappears from the print preview Expected results: The canvas should have remained in the preview. Running Aurora 13.0a2 (2012-03-23) on Windows 7 x64.
That's... very odd. I can't reproduce that on my Linux (m-c, though) build. I'll give Windows a shot, I guess, but it'll be a bit over a week until I'm back to the Windows machine.
I can reproduce on Linux with http://www.williammalone.com/articles/html5-canvas-example/downloads/simpleExample.html
Er, nevermind. I was looking at the wrong parts of the page. I can reproduce this, and it actually shows what looks like a much bigger problem in the landscape/portrait switching. I filed bug 739004 on it.
Added the 'Display of canvas elements' test in Litmus under Firefox>Aurora>Aurora Full Functional Tests (FFTs)>FX Aurora FFT>Printing
Flags: in-litmus? → in-litmus+
Verified fixed on Firefox 12b3: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0 Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
You need to log in before you can comment on or make changes to this bug.