Bug 45894 – 3D transformed elements hide when showing the print dialog

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jurriaan Mous]

Created attachment 67801 [details]
reduced testcase

Every 3d transformed elements or an element with perspective is hidden from the screen when displaying print dialog.  3D transformed elements return when dialog is dismissed.
Even when those 3d transformed divs have a display:none for @media: print they are hidden from view.

Solution: Keep showing the 3d transformed objects on screen while showing print dialog. Especially when those are not used in the print.

(On current project with 3d transformed page transitions in webkit the print dialog hides everything so the user sees a blank background.)

I included an example HTML with the problem visible when print dialog is called.

[Simon Fraser (smfr)]

<rdar://problem/7441593>

[Tim Horton]

Created attachment 123999 [details]
patch

[Tim Horton]

My patch a) only fixes WebKit2 and b) doesn't have any tests. Is there any way to do a pixel test when the printing dialog is up? Not sure how that'll work in DRT.

[Andy Estes]

(In reply to comment #3)
> My patch a) only fixes WebKit2 and b) doesn't have any tests. Is there any way to do a pixel test when the printing dialog is up? Not sure how that'll work in DRT.

r=me, but I think you might be able to write a test using the setPrinting() method on LayoutTestController. You should try to do this first.

[Andy Estes]

Comment on attachment 123999 [details]
patch

Clearing my r+. Tim's going to write a test.

[Simon Fraser (smfr)]

Comment on attachment 123999 [details]
patch

Does WebKit1 need fixing too?

[Jurriaan Mous]

Chrome does not show the problem.
Omniweb with Webkit1 does not support 3D transforms so the problem is not present there. 
The iPad also does not show the problem when printing.

So the problem only remains with devs like me sticking to old Safaris or maybe other webkit1 browsers which do support 3D transforms.  (We still use the old Safari shell on the side because we need a specific development plugin unsupported in webkit2.)

If possible and not too much trouble, Yes. :) 
But I can live with a no.

(In reply to comment #6)
> (From update of attachment 123999 [details])
> Does WebKit1 need fixing too?

[Simon Fraser (smfr)]

That comment was really directed at Tim.

[Tim Horton]

(In reply to comment #8)
> That comment was really directed at Tim.

It does! Oddly, though, things seem to be a lot better with WebKit 1. The layers stay in place, they just get clipped by something. Do you know what might be doing the clipping? I dumped the layer tree and they're identical before and during printing in WK1.

[Tim Horton]

(In reply to comment #9)
> (In reply to comment #8)
> > That comment was really directed at Tim.
> 
> It does! Oddly, though, things seem to be a lot better with WebKit 1. The layers stay in place, they just get clipped by something. Do you know what might be doing the clipping? I dumped the layer tree and they're identical before and during printing in WK1.

Wait, nevermind, I got my files mixed up.

[Tim Horton]

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > That comment was really directed at Tim.
> > 
> > It does! Oddly, though, things seem to be a lot better with WebKit 1. The layers stay in place, they just get clipped by something. Do you know what might be doing the clipping? I dumped the layer tree and they're identical before and during printing in WK1.
> 
> Wait, nevermind, I got my files mixed up.

Before Cmd-P:


(layer [548.5 654 0] [0 0 1097 1308] [0.5 0.5 0]
(sublayers (array
(layer [548.5 654 0] [0 0 1097 1308] [0.5 0.5 0] .......

After Cmd-P:

(layer [548.5 203 0] [0 0 1097 1308] [0.5 0.5 0] .......

the remainder is identical.

[Tim Horton]

Also, I can't write a test for the WK2 case: https://bugs.webkit.org/show_bug.cgi?id=42693

[Tim Horton]

(In reply to comment #6)
> (From update of attachment 123999 [details])
> Does WebKit1 need fixing too?

Adele thinks we should land the WebKit2 fix and have another bug to fix WK1; I can't come up with any way to test it (I've hacked up WebKitTestRunner to put us into printing mode, but then we get garbage out the other end; I'm assuming this is because depending on the view to not repaint in print mode is broken with WebKitTestRunner, seeing as how there don't seem to be tests that check that).

[Andy Estes]

Comment on attachment 123999 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=123999&action=review

r=me. Please file a bug to track fixing this in WebKit1 as well.

> Source/WebCore/ChangeLog:12
> +        No new tests.

Please add a brief comment explaining why this isn't testable (no support for setPrinting() in WKTR, etc.).

> Source/WebCore/platform/graphics/ca/LayerFlushScheduler.h:49
> +    bool isSuspended() { return m_isSuspended; }

I'd prefer this method to be const.

[Tim Horton]

Landed in http://trac.webkit.org/changeset/106083; follow-up WK1 bug at https://bugs.webkit.org/show_bug.cgi?id=77180