Chrome browser - Blank print preview with Chrome App on iPad Air iOS 9.3.1
Reported by
yyefet@chromium.org,
Jun 6 2016
|
||||||||||||
Issue descriptionVersion: 50.0.2661.95 OS: iOS version 9.3.1 (iPad Air model is MD788B/B) Description: - Enterprise customer is unable to generate PDFs from their Salesforce account on Chrome Browser for Ipad. - Other PDFs open with no issue. - The customer provided a sample PDF. - The issue also occurs with Chrome on iOS 9.3.2. - It seems as if something goes wrong when encoding the PDF from Chrome for the iOS system print preview. What steps will reproduce the problem? 1. Click on a link to open a PDF document. 2. When the PDF opens on a new tab, open the options menu. 3. Click the ‘Print’ option for this tab 4. On the print preview page, the preview is completely empty. When printing the document, the page will also be blank. Note: - The customer has tested the exact same steps on Safari on iPad and does not experience the issue. - Issue also persisted on incognito tab on Chrome. What is the expected output? PDF should generate and should display in print preview and print the contents. What do you see instead? PDF does not generate, blank print preview, printer prints a blank page. PII Protected sample document: https://drive.google.com/a/google.com/folderview?id=0B6fESMmJITTNUWhZazkyS2xWYUU&usp=sharing
,
Jun 9 2016
,
Jun 10 2016
This may be because we are currently validating whether or not to print using the PDF print flow by using the path extension. So, if the URL does not end in ".pdf", it does not work.
,
Jun 27 2016
,
Sep 6 2016
Not going to be able to dig into this in the near term, but we should fix. Assigning to pkl for retriage.
,
Sep 6 2016
,
Sep 7 2016
Is there an estimated level of effort for the fix? Looks like it might be happening in limited situations only? (comment #3)
,
Sep 7 2016
It is not completely clear what the exact failure is that was reported, since we do not have access to the original test case hosted on salesforce. But, the reason why the PDF hosted on Google Drive fails is that the Google Drive URL does not end in ".pdf". So, the fix involves finding another way to determine if the page that is loaded is a PDF. I looked into a bit more, and I think the best option would be to pass web state to the print code, and get the MIME type from there. Assuming this fix works, then it would take <1 day. If not, then it would take a few days.
,
Sep 30 2016
M55 is branching soon. This currently not high on our list, but if this is still important for Enterprise, please let us know and we can consider it for either M56 or M57.
,
Oct 8 2016
Removing PDF component because the Chrome PDF Viewer does not exist on iOS.
,
Jul 27 2017
Print preview doesn't exist on iOS, so this isn't Print Preview... labeling printing for now, not sure if there is another component that would be better.
,
Jul 30
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 30
,
Nov 21
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by yyefet@chromium.org
, Jun 6 2016