Bug 45894 - 3D transformed elements hide when showing the print dialog
Summary: 3D transformed elements hide when showing the print dialog
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.6
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2010-09-16 08:45 PDT by Jurriaan Mous
Modified: 2012-01-26 20:47 PST (History)
3 users (show)

See Also:


Attachments
reduced testcase (731 bytes, text/html)
2010-09-16 08:45 PDT, Jurriaan Mous
no flags Details
patch (6.42 KB, patch)
2012-01-25 13:28 PST, Tim Horton
aestes: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jurriaan Mous 2010-09-16 08:45:47 PDT
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.
Comment 1 Simon Fraser (smfr) 2010-12-06 10:52:28 PST
<rdar://problem/7441593>
Comment 2 Tim Horton 2012-01-25 13:28:53 PST
Created attachment 123999 [details]
patch
Comment 3 Tim Horton 2012-01-25 13:36:51 PST
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.
Comment 4 Andy Estes 2012-01-25 14:44:35 PST
(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.
Comment 5 Andy Estes 2012-01-25 16:57:39 PST
Comment on attachment 123999 [details]
patch

Clearing my r+. Tim's going to write a test.
Comment 6 Simon Fraser (smfr) 2012-01-26 07:16:50 PST
Comment on attachment 123999 [details]
patch

Does WebKit1 need fixing too?
Comment 7 Jurriaan Mous 2012-01-26 08:30:31 PST
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?
Comment 8 Simon Fraser (smfr) 2012-01-26 08:46:15 PST
That comment was really directed at Tim.
Comment 9 Tim Horton 2012-01-26 11:33:08 PST
(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.
Comment 10 Tim Horton 2012-01-26 11:35:06 PST
(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.
Comment 11 Tim Horton 2012-01-26 11:45:26 PST
(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.
Comment 12 Tim Horton 2012-01-26 12:06:17 PST
Also, I can't write a test for the WK2 case: https://bugs.webkit.org/show_bug.cgi?id=42693
Comment 13 Tim Horton 2012-01-26 17:36:39 PST
(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).
Comment 14 Andy Estes 2012-01-26 17:45:06 PST
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.
Comment 15 Tim Horton 2012-01-26 20:47:04 PST
Landed in http://trac.webkit.org/changeset/106083; follow-up WK1 bug at https://bugs.webkit.org/show_bug.cgi?id=77180