Bug 151386 – WKWebView does not render PDF pages in AirPrint

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

Created attachment 265744 [details]
Reproduction case.

Summary:
When one attempts to AirPrint a PDF open in WKWebView using [WKWebView viewPrintFormatter], the previews and the printed output are blank. 
Note that Safari on iOS prints normally. This is reproducible both with iOS 9.1 SDK's WebKit and a nightly checkout. 

Is there a workaround Safari uses?

Steps to Reproduce:
Unzip attached project, build & run. A pdf document will be loaded, and once it's loaded, the print dialog will open.
Note that the repro is linked with iOS SDK's WebKit. You may want to relink it to your own WebKit.framework.

Expected Results:
Preview in print dialog shows a small PDF preview. PDF prints normally.

Actual Results:
Previews in print dialog shows a blank page. Printed page is blank.

Version:
iOS 9.1; tot.

Notes:
You can debug printing by downloading Hardware IO Tools for Xcode 7 on Apple Developer Portal and running an AirPrint simulator.
Also filed rdar://23556241.

[Andy Estes]

One workaround is to set UIPrintInteractionController's printingItem to an NSData containing the PDF. Unfortunately this probably requires you to load the PDF a second time.

[Eugene But]

Thank you for providing a workaround. Downloading PDF may not always work, because WKWebView does not provide reliable API to get cookie (NSHTTPCookieStorage is not always up to date). However being broken only in cases when auth is required is better than being always broken.

Please let us know if you see any alternative workarounds. Thanks!

[Andy Estes]

rdar://problem/22499157

[Andy Estes]

The issue here is that _WKWebViewPrintFormatter's _totalScaleFactor is 0 for PDFs. Setting it to 1 instead fixes the attached test case. We probably need to compute a per-page scale factor for PDFs.

[Andy Estes]

Created attachment 280935 [details]
Patch

[WebKit Commit Bot]

Attachment 280935 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/ios/WKContentView.mm:632:  The parameter name "handle" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 17 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Tim Horton]

Comment on attachment 280935 [details]
Patch

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

> Source/WebKit2/UIProcess/WebPageProxy.h:260
> +using DrawToPDFCallback = GenericCallback<const IPC::DataReference&>;

Interesting! Why using instead of typedef like the others? Should we change the others?

> Source/WebKit2/UIProcess/WebPageProxy.h:910
> +        uint32_t computePagesForPrintingAndDrawToPDF(uint64_t frameID, const PrintInfo&, DrawToPDFCallback::CallbackFunction&&);

indentation is weird.

[Andy Estes]

(In reply to comment #7)
> Comment on attachment 280935 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=280935&action=review
> 
> > Source/WebKit2/UIProcess/WebPageProxy.h:260
> > +using DrawToPDFCallback = GenericCallback<const IPC::DataReference&>;
> 
> Interesting! Why using instead of typedef like the others? Should we change
> the others?

using doesn't make me think about which order things go in like typedef does, and it's more C++11y, but I don't know if we should change the others!

> 
> > Source/WebKit2/UIProcess/WebPageProxy.h:910
> > +        uint32_t computePagesForPrintingAndDrawToPDF(uint64_t frameID, const PrintInfo&, DrawToPDFCallback::CallbackFunction&&);
> 
> indentation is weird.

Oops. Will fix.

Thank you for the review!

[Andy Estes]

Created attachment 280939 [details]
Patch

[WebKit Commit Bot]

Attachment 280939 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/ios/WKContentView.mm:632:  The parameter name "handle" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 17 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[WebKit Commit Bot]

Comment on attachment 280939 [details]
Patch

Rejecting attachment 280939 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'build', '--no-clean', '--no-update', '--build-style=release', '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
CompileC /Volumes/Data/EWS/WebKit/WebKitBuild/WebKit2.build/Release/WebKit.build/Objects-normal/x86_64/_WKWebViewPrintFormatter.o UIProcess/_WKWebViewPrintFormatter.mm normal x86_64 objective-c++ com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)

Failed to run "['Tools/Scripts/build-webkit', '--release']" exit_code: 65
d/Objects-normal/x86_64/_WKWebViewPrintFormatter.o UIProcess/_WKWebViewPrintFormatter.mm normal x86_64 objective-c++ com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)

Full output: http://webkit-queues.webkit.org/results/1474107

[Andy Estes]

Created attachment 280951 [details]
Patch

[WebKit Commit Bot]

Attachment 280951 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/ios/WKContentView.mm:632:  The parameter name "handle" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 17 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[WebKit Commit Bot]

Comment on attachment 280951 [details]
Patch

Clearing flags on attachment: 280951

Committed r201888: <http://trac.webkit.org/changeset/201888>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.