Issue metadata
Sign in to add a comment
|
Chrome pdf viewer does not working properly..
Reported by
fahria...@gmail.com,
Dec 28
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
Steps to reproduce the problem:
1. I produce pdf on web page dynamically.
2. All browsers i tested view successfully but Chrome latest versions.
3. I changed html code and now solved the problem on my site.
What is the expected behavior?
The pdf file expected be viewed in a browser window. Php script works well, but chrome does display a gray empty screen however the ready pdf is downloadable.
What went wrong?
İ think the <embed> html5 element does not working because of the Chrome's related html code. In html code there is no <head> tag between <html> tag and <body> tag however there are defined <link> and <style> tags at that area.
Chrome's generated html code is below:
<html>
<link type="text/css" id="dark-mode" rel="stylesheet" href="">
<style type="text/css" id="dark-mode-custom-style"></style>
<body style="height: 100%; width: 100%; overflow: hidden; margin: 0px; background-color: rgb(82, 86, 89);">
<embed width="100%" height="100%" name="plugin" id="plugin" src="example.com/example.pdf" type="application/pdf" internalinstanceid="9">
</body>
</html>
Did this work before? Yes Working on my MacOs 10.6.8, Chrome version 49.0.2623.112 (64-bit)
Does this work in other browsers? Yes
Chrome version: 49.0.2623.112 Channel: n/a
OS Version: OS X 10.6.8
Flash Version: Shockwave Flash 22.0 r0
I solved the problem on my site by adding <head> tag to the html code as below and now <embed> html5 element is working as expected:
<html>
<head>
<style type="text/css" media="all"><!--
body { margin: 0 0 0; }
.pdf-wh { width: 100%; height: 100%; }
--></style>
</head>
<body>
<embed class="pdf-wh" width="100%" height="100%" src="example.com/example.pdf" type="application/pdf"></embed>
</body>
</html>
,
Dec 31
,
Jan 1
Thanks for filing the issue! From comment#0, it's clear that the issue has been resolved by adding <head> tag to the html code and as already mentioned in C#1 about the version in which it worked was very old, hence removing Needs-Bisect label. Please feel to add the label back if required. @Reporter: As asked in C#1, could you please share a sample test file, which helps us to triage this further in a better way.
,
Jan 1
Test Platform: Win 10, Chrome Version: 71.0.3578.98 https://proparts-catalog.com/?brand=Mercedes-Benz&page=detailed If you wish to get item list in the generated pdf, create php session variable by making item selections with this sample link by clicking [+] buttons then test below two pdf generation links: 1- Chrome Default (Unexpected result sample link): https://proparts-catalog.com/php/makePDF.php?d=0 2- Working Html Code (Expected result sample link): https://proparts-catalog.com/html/makePDF.html
,
Jan 1
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 1
Pdf download link works well: https://proparts-catalog.com/php/makePDF.php?d=1
,
Jan 10
falken: is this bug 916514 ? I'm having a bit of trouble getting https://proparts-catalog.com/php/makePDF.php?d=0 to fail right now, but I did get it to fail earlier. When it failed, the JS console had an error from sw.js.
,
Jan 11
Yes I think this is bug 916514 . I could repro in Dev 73.0.3664.3 but not local build 73.0.3667.0. It's expected to be fixed in versions >=73.0.3665.0. fahriakar: Does this work for you on a version >= 73.0.3665.0?
,
Jan 11
,
Jan 11
Thanks to falken@chromium.org's point of view. Falken: Before test on version 73.0.3665.0 to clear the problem's source, I've created two subdomains for testing purposes as https://bugsw.proparts-catalog.com and https://bug.proparts-catalog.com First subdomain registeres an empty service worker (named as sw.js), second does not. Through my tests Comment#7 and Comment#8 seems to be right on pointing to service worker related bug 916514 . - - - - - - - - - - - - - - - Test Platform: Win 10, Chrome Version: 71.0.3578.98 (64 bit) - - - - - - - - - - - - - - - WITHOUT Service Worker, checked 4 Tests: ALL TESTS SUCCESSFULL: 1-Static PDF, 2-Embed Static PDF, 3-Dynamic PDF, 4-Embed Dynamic PDF. WITH Activated Empty Service Worker, checked 4 Tests: ALL TESTS SUCCESSFULL: 1-Static PDF, 2-Embed Static PDF, 3-Dynamic PDF, 4-Embed Dynamic PDF. - - - - - - - - - - - - - - - The new link below includes WITH and WITHOUT Activated Empty Service Worker test links: (All 8 links work great on the Test Platform.) https://bugsw.proparts-catalog.com/index.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - For Note: Problem occurs only on this link: https://proparts-catalog.com/php/makePDF.php?d=0 My opinion: It seems the problem is related with the sw.js registered at this link and its' fetching cache, because the new empty sw.js does not cause the same problem (sw.js registered on this link was created with PWABuilder). I will work on this issue and will report the sw.js code changes as "before" and "after" here. - - - - - - - - - - - - - - -
,
Jan 12
c#10: Thanks for the details, and yes that all matches my knowledge of the bug. Before the fix in 73.0.3665.0, the bug occurs when a service worker intercepts the request and provides a response using respondWith(). An empty sw.js would not exhibit the bug. See https://bugs.chromium.org/p/chromium/issues/detail?id=916514#c38. To confirm, does the bug still occur for you in versions >= 73.0.3665.0?
,
Jan 21
(2 days ago)
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by phistuck@chromium.org
, Dec 30