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.
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.
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!
rdar://problem/22499157
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.
Created attachment 280935 [details] Patch
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.
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.
(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!
Created attachment 280939 [details] Patch
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.
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
Created attachment 280951 [details] Patch
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.
Comment on attachment 280951 [details] Patch Clearing flags on attachment: 280951 Committed r201888: <http://trac.webkit.org/changeset/201888>
All reviewed patches have been landed. Closing bug.