Closed Bug 734406 Opened 13 years ago Closed 12 years ago

<canvas> elements no longer print (or preview)


(Core :: Layout, defect, P1)

12 Branch



Tracking Status
firefox12 - verified
firefox13 - ---


(Reporter: suttree, Assigned: bzbarsky)



(Keywords: regression, Whiteboard: [qa+])


(1 file)

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:


Or the following:

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 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)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111222 Firefox/12.0a1 ID:20111222031055
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111222 Firefox/12.0a1 ID:20111222033040

Regression window(m-c)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111221 Firefox/12.0a1 ID:20111221133437
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20111221 Firefox/12.0a1 ID:20111221140437

70af9bf2a4dc	Boris Zbarsky — Bug 302566. Show canvas fallback content when script is disabled. r=tnikkel
Blocks: 302566
Component: Untriaged → Layout
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: untriaged → layout
Hardware: x86_64 → x86
Version: 11 Branch → 12 Branch
Linux build also fails.
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120309 Firefox/13.0a1 ID:20120309062528
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
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.
Assignee: nobody → bzbarsky
Priority: -- → P1
Whiteboard: [need review]
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?
Closed: 12 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+
Timothy, thanks!
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.
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.
Flags: in-testsuite?
Flags: in-litmus?
Whiteboard: [qa+]
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.