Closed
Bug 1083740
Opened 10 years ago
Closed 10 years ago
pdf view in Firefox not show pdf content
Categories
(Core :: Networking: HTTP, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: derek, Unassigned)
References
Details
(Keywords: regression, testcase, Whiteboard: Fixed by bug 1088850)
Attachments
(1 file)
66.19 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 Steps to reproduce: I have an ASP.Net application which creates a pdf file using the Crystal Reports and the file is written to an output stream. This process worked fine in Firefox 32 but in 33 the PDF does not show. The same application accessed from IE and Chrome displays correctly. This has only become an issue on PCs that have version 33 installed.
Reporter | ||
Updated•10 years ago
|
Severity: normal → major
I thik it's a dupe of bug 1083135. Derek, do you have a minimal self-contained testcase to attach, please? (no php, asp files, only HTML/CSS if possible) It would help to debug.
Flags: needinfo?(derek)
Keywords: testcase-wanted
Reporter | ||
Comment 2•10 years ago
|
||
Unfortunately not. The PDF is generated in the code behind of an ASP.Net page. How else could I assist?
Flags: needinfo?(derek)
Could you provide a public access (like a demo) or a private access with guest account/limited rights? If not, you may install the tool mozregression on a testing machine (see http://mozilla.github.io/mozregression/ for details) to find a possible regression range in FF33. Just paste the console output (pushlog), no need to bisect. FF33 nightlies started in June 2014, so --good=2014-06-01 is a good start.
Flags: needinfo?(derek)
Keywords: regressionwindow-wanted
Same issue. PDF generated by fpdf using php. Not a lot images. Text, lines, boxes and 1 logo. Also behind a firewall and not very testable.
Comment 5•10 years ago
|
||
Same Issue. Not only PDF also XLS/DOC generated by a ASP.NET applicattion with Crystal Reports 2008, are not shown/generated since Firefox 33. Applicattion is working correctly in Chrome or IE.
Comment 7•10 years ago
|
||
I am not able to provide a TEST enviroment, the application is behing a VPN. Can I help you in another way provideing information ??
Yes, follow my comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1083740#c3
Tried to isolate parts of the php environment but sadly when I extracted what I thought were the minimal pieces the bug did not replicate. I can try to capture the pdf doc that is created by the application and fails but I can't seem to find a way to get it out of the firefox developer pane. I can see the PDF created in the response tab but I don't think if I cut and paste it out that all the hidden characters will be preserved. Anyway I tried on a mac (which does not show the bug) will try to post what I pasted into TextWrangler.
Comment 10•10 years ago
|
||
Let me know how I can better capture the file if this is not helpful.
Comment 11•10 years ago
|
||
Hi Loic, this version is running Ok, I am still trying newer versions. Is this info usefull for you??? I will continue testing. Let you konw!! mozversion INFO | application_buildid: 20140612080636 mozversion INFO | application_changeset: edf5e2dc9198 mozversion INFO | application_display_name: Nightly mozversion INFO | application_name: Firefox mozversion INFO | application_repository: https://hg.mozilla.org/integration/moz illa-inbound mozversion INFO | application_version: 33.0a1 mozversion INFO | platform_buildid: 20140612080636 mozversion INFO | platform_changeset: edf5e2dc9198 mozversion INFO | platform_repository: https://hg.mozilla.org/integration/mozill a-inbound Testing inbound build with timestamp 1402561951, revision bd5ebedffaf953e1f86e00 fd63208fc71520fcdf Downloading build from: http://inbound-archive.pub.build.mozilla.org/pub/mozilla .org/firefox/tinderbox-builds/mozilla-inbound-win32/1402561951/firefox-33.0a1.en -US.win32.zip ===== Downloaded 100% ===== Installing nightly mozversion INFO | application_buildid: 20140612083231 mozversion INFO | application_changeset: bd5ebedffaf9 mozversion INFO | application_display_name: Nightly mozversion INFO | application_name: Firefox mozversion INFO | application_repository: https://hg.mozilla.org/integration/moz illa-inbound mozversion INFO | application_version: 33.0a1 mozversion INFO | platform_buildid: 20140612083231 mozversion INFO | platform_changeset: bd5ebedffaf9 mozversion INFO | platform_repository: https://hg.mozilla.org/integration/mozill a-inbound Starting nightly (revision: bd5ebedffaf9) Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry ', or 'exit' and press Enter):
Comment 12•10 years ago
|
||
No need to bisec, just stop when you see the pushlog.
Comment 13•10 years ago
|
||
I don't know how to use the PushLog I think that this is what you need: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80431d4fd0da&tocha nge=bb35d1b73634 Ensuring we have enough metadata to get a pushlog... Getting http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/06/2014-06-1 7-03-02-03-mozilla-central/firefox-33.0a1.en-US.win32.txt Last good revision: 80431d4fd0da (2014-06-16) First bad revision: bb35d1b73634 (2014-06-17) Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80431d4fd0da&tocha nge=bb35d1b73634 ... attempting to bisect inbound builds (starting from previous week, to make su re no inbound revision is missed) Getting http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/06/2014-06-0 9-03-02-02-mozilla-central/firefox-32.0a1.en-US.win32.txt Getting inbound builds between 9305a8ec77fe and bb35d1b73634 Let me konw if you need more Info. Thanks a lot in advance.
Comment 14•10 years ago
|
||
Yes, thanks, the 1st link is enough.
Comment 15•10 years ago
|
||
Maybe I'm wrong but it could be a side-effect of bug Bug 237623. Reporters, can you post the request header when your application is sending the file to Firefox? Just open the web console and click on the network request to read the header.
Comment 16•10 years ago
|
||
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Cache-Control: max-age=0
Comment 17•10 years ago
|
||
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Worked on 32. Broke on 33. Mac and Windows. Previously I thought Mac was OK but I notice from the request header I had not updated.
Reporter | ||
Comment 18•10 years ago
|
||
I can provide a public test environment. Go to the URL below: www.mytrellidor.co.za/toostest user = mozilla pwd = mozilla Click menu option reports => management reports => budget YTD Then click the "View" button and a PDF report will open up in a pop-up window Let me know when you are done so I can remove the account.
Flags: needinfo?(derek)
Comment 19•10 years ago
|
||
(In reply to mmagarelli@gmail.com from comment #5) > Same Issue. Not only PDF also XLS/DOC generated by a ASP.NET applicattion > with Crystal Reports 2008, are not shown/generated since Firefox 33. > Applicattion is working correctly in Chrome or IE. Yes, that's the same on my site, it happens since this week. I look into those bad links i found all those content type was set to application/octet-stream has same issue context.HttpContext.Response.ContentType = "application/octet-stream"; I debugged into my code, when i clicked that link it seems never hits the server side code at all. if i change to others such as "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" that works. And also that Microsoft Reporting server is broken as well. I guess it's using application/octet-stream" too.
Comment 20•10 years ago
|
||
(In reply to Derek Crompton from comment #18) > I can provide a public test environment. Go to the URL below: > > www.mytrellidor.co.za/toostest > > user = mozilla > pwd = mozilla > > Click menu option reports => management reports => budget YTD > > Then click the "View" button and a PDF report will open up in a pop-up window > > Let me know when you are done so I can remove the account. Thanks, it helped. And it confirms what I suspected, it's a side effect of Bug 237623. Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80431d4fd0da&tochange=bb35d1b73634 There is a possible explication here: https://bugzilla.mozilla.org/show_bug.cgi?id=1083090#c8 When I click on "View" to open the PDF in a pop-up, the header response is: X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Vary: Accept-Encoding Server: Microsoft-IIS/7.5 Date: Fri, 17 Oct 2014 15:49:54 GMT Content-Type: text/html; charset=utf-8 Content-Length: 12643 Content-Encoding: gzip Cache-Control: private NB: Derek, could you keep your tescase open until a dev investigates the issue.
Blocks: 237623
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: HTTP
Ever confirmed: true
Flags: needinfo?(mcmanus)
Product: Firefox → Core
Comment 22•10 years ago
|
||
thanks for the test case www.mytrellidor.co.za/toostest the server has an http framing bug. It generates a http/1.1 keep-alive eligible response with an invalid chunked encoding. The message body consists of a single chunk 70272 (0x11280) bytes in size without including a final 0 chunk. All valid chunked encodings end with a 0 chunk. We interpret it as truncated response and consider than an error. That's what 237623 was all about - correctly identifying truncated downloads. We think that server software with this problem is a very long tail of the internet (most of it are custom scripts) and can generally be fixed by being updated and at this point we are preferring to accurately catch the real network error cases. Watching the bug traffic is one way we'll know if we're wrong - so thanks for filing. Your best bet is to get the server fixed. You could also work around it by generating HTTP/1.0 responses for that script - we don't enforce this for http/1.0
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(mcmanus)
Resolution: --- → WONTFIX
Comment 24•10 years ago
|
||
Common Loic, you closed the bug without a solution , and we are a lot of us with the same problem. I don't think the problem is in the server. Same problem is reproduced in Win 7 32/64bits, Win 2003 Server /Windows 2008 Server and Mac. Last week my apps worked excellent generating reports with Crystal Reports and this FF33 version broke them.
Comment 25•10 years ago
|
||
I didn't close anything and Derek was the only to provide a tescase when I asked. Maybe you can provide HTTP logs: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Comment 26•10 years ago
|
||
(In reply to mmagarelli@gmail.com from comment #24) > Common Loic, you closed the bug without a solution , Don't blame Loic - that was me. And there were two solutions provided in my comment. 1] fix the server by getting the http encoding correct 2] workaround the issue by generating an http/1.0 response the error is in the server, so the burden is going to be on the server. > and we are a lot of us > with the same problem. I don't think the problem is in the server. please see above - the problem is an incorrect chunked encoding in the server (probably crystal reports itself). I'd be happy to contribute to a bug with SAP (it looks like they own that) if you start one. the basic issue is that what is being generated is truncated and broken content according to http. We have two different events that can generate truncated content and they basically look the same and are going to receive the same treatment: * buggy servers * real network errors #1 If we choose to believe that its caused by buggy servers (and therefore ignore it) then real network errors are covered up.. and we end up saving and displaying genuinely truncated content. That was the old behavior - it generated lots of bug reports. #2 If we choose to believe that it is caused by real network errors then we can report the error appropriately. That's the new behavior. Both approaches have pros and cons. However #2 favors compliant implementations and puts the burden on buggy software (not meant prejoratively, I've written many bugs) to fix things where #1 breaks things for implementations that have done nothing wrong. We made the change based on the judgment that these errors weren't dominated by buggy servers anymore. The beta period didn't provide any feedback to the contrary and I'm still open minded about what the new release will bring (so again, thank you for the input) - but I'm certainly inclined to try and stay the course.
Comment 27•10 years ago
|
||
fwiw - this is a post of someone in an all MS environment with a similar problem http://bytes.com/topic/asp-net/answers/634506-problem-displaying-binary-pdf-content-iis7 If you go all the way to the bottom they resolved it by adding Response.End() to their ASP.. which I'm just guessing is necessary to make it generate valid HTTP in this case. ASP programming isn't something I'm really familiar with - I just thought I'd pass it on.
Comment 28•10 years ago
|
||
The system we have is running apache 2.0 with PHP 5.2.6 on Windows XP. It's kind of old but not stone age old. I don't know that you can insist that the web all be updated to work with Firefox 33+. The more likely behavior is that the affected users go to Chrome (that's what we were instructed to tell our in-house users so far; who knows if they ever switch back?). Firefox is dropping in share monthly. Saying you won't support older servers is not going to help your share much. The pdf is generated by fpdf. I'm not sure I can say at this point which component is bad and needs updating: apache, php, fpdf. I tried adding flush(); and end(); to the page which upon googling were the mentioned equivalents to response.end but neither worked. So I don't know I could fix this even if I wanted to. I might try upgrading the server and php over the weekend but I'm sure that will break other things in this legacy application. Maybe not the server but php more likely. If it's a server issue it's a bunch of server types. So far it seems like versions of both IIS and Apache. Why not just require strict html5 compliance or not display a page? Wipe out a good portion of the internet. Who cares about market share.
Comment 29•10 years ago
|
||
Sorry is Apache 2.2
Comment 30•10 years ago
|
||
(In reply to Scott from comment #28) > > If it's a server issue it's a bunch of server types. So far it seems like > versions of both IIS and Apache. I would think in this case its more specific than the iis/apache container - i.e. take a look at the php script in question. If you'd like to post a URL or a wireshark capture of the pdf I can help you diagnose your exact problem as my previous comments were about a url posted by another reporter. There are a few different problems with framing that could occur and yours might not be a end-chunk as it was for the other site. > > Why not just require strict html5 compliance or not display a page? Wipe > out a good portion of the internet. Who cares about market share. obviously compliance for compliance sake is not the idea. I described in comment 26 the drivers for the change (i.e. the old behavior was harming cases that actually were in compliance - and that now works much better) and that we don't think a good portion of the Internet will be impacted by the shift. That's not the same thing as saying nobody will be impacted. If we're wrong, we'll make need to make another change.
Comment hidden (off-topic) |
Comment 32•10 years ago
|
||
Please, no advocacy in the bug report.
Comment 33•10 years ago
|
||
(In reply to Scott from comment #28) > Why not just require strict html5 compliance or not display a page? Wipe > out a good portion of the internet. Who cares about market share. We must display the page to comply with the spec. The html5 spec requires that compliant browsers must display invalid pages.
Comment 37•10 years ago
|
||
Hello, we meet the same issue in our website. It was worked perfectly until version 33 of Firefox. Is a fix expected ? Regards
Comment 38•10 years ago
|
||
this should be resolved by 1088850 in 33.1
Comment 39•10 years ago
|
||
Thank your for your answer. Is there an ETA for this release ?
Comment 40•10 years ago
|
||
(In reply to Maxence C from comment #39) > Thank your for your answer. > Is there an ETA for this release ? In 10 days: https://wiki.mozilla.org/Firefox/Decade#Firefox.27s_10_Year_Anniversary
Comment 41•10 years ago
|
||
Thank you. I hope this release will fix our problem. Have a good day!
Comment 42•10 years ago
|
||
Firefox nightly build 36.0a1 does not produce the same problem with downloadable pdfs. While I am nervous relying on a nightly build, I will not go back to Chrome. I hope that 33.1 comes soon.
Comment 44•10 years ago
|
||
Patrick, I set this bug as fixed according to your comment #38, I think it's better for users hitting this issue than wontfix.
Comment 47•10 years ago
|
||
Sorry, but the bug isn't solved. Please check: http://www.infraroodwarmteshop.nl/attachment.php?id_attachment=80
Comment 48•10 years ago
|
||
(In reply to WebShopDesigners from comment #47) > Sorry, but the bug isn't solved. > Please check: > http://www.infraroodwarmteshop.nl/attachment.php?id_attachment=80 It's fixed in 33.1 (next week) and 34+. Just wait for the next release. Anyway this server is really bad configured, filenames with spaces are cut (bug 221028), file size is not specified.
Comment 49•10 years ago
|
||
(In reply to WebShopDesigners from comment #47) > Sorry, but the bug isn't solved. > Please check: > http://www.infraroodwarmteshop.nl/attachment.php?id_attachment=80 It's still broken with e10s enabled in Nightly, I filed bug 1095804 for that.
Comment 51•10 years ago
|
||
I have applied version 33.1 of firefox on my computer and ... it works perfectly ! Thanks for the fix Have a good day
Comment 52•10 years ago
|
||
just updated to 33.1 and unfortunately i'm still having the same problem with certain pdf files, even in safe-mode. referencing my report for duplicate bug 1095997, these are the sections of 2 of the PDF URLs that won't open - same problem still happening. /StatementContent.xhtml?statement=0 /ebillViewPDF.do?stmtDate=June 25th, 2014&subActionId=6706&inline=true
Comment 53•10 years ago
|
||
(In reply to shape5 from comment #52) > just updated to 33.1 and unfortunately i'm still having the same problem > with certain pdf files, even in safe-mode. referencing my report for > duplicate bug 1095997, these are the sections of 2 of the PDF URLs that > won't open - same problem still happening. > > /StatementContent.xhtml?statement=0 > /ebillViewPDF.do?stmtDate=June 25th, 2014&subActionId=6706&inline=true We need a public testcase to test and debug. Internal links don't really help.
Comment 54•10 years ago
|
||
you mean the websites where they occur? please let me know exactly what info or testing procedure you need.
Comment 55•10 years ago
|
||
Yes, post URL showing the issue up.
Comment 56•10 years ago
|
||
the first one was from https://online.americanexpress.com and the 2nd from https://www3.onlinecreditcenter6.com
Comment 57•10 years ago
|
||
We need the direct links to the PDF documents, if they are public.
Comment 58•10 years ago
|
||
ok - i listed the wrong first site before anyway. these are the direct links to the pdfs that won't open and hang on the spinning wheel: https://c.comenity.net/express/secure/accountactivity/StatementContent.xhtml?statement=2 https://www3.onlinecreditcenter6.com/consumergen2/ebillViewPDF.do?stmtDate=June%2025th,%202014&subActionId=6706&inline=true
Comment 59•10 years ago
|
||
but these require login as they are invoices.
Comment 60•10 years ago
|
||
So they aren't public. :/
Comment 61•10 years ago
|
||
well, that's what i mentioned initially in the bug i reported which i linked: Bug 1095997 - that they were PDFs from credit card statements.
You need to log in
before you can comment on or make changes to this bug.
Description
•