Closed Bug 1083740 Opened 10 years ago Closed 10 years ago

pdf view in Firefox not show pdf content

Categories

(Core :: Networking: HTTP, defect)

33 Branch
x86_64
Windows 7
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: derek, Unassigned)

References

Details

(Keywords: regression, testcase, Whiteboard: Fixed by bug 1088850)

Attachments

(1 file)

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.
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
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)
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.
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.
Reporters, can you provide a testcase? It would help a lot, thanks.
I am not able to provide a TEST enviroment, the application is behing a VPN. Can I help you in another way provideing information ??
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.
Let me know how I can better capture the file if this is not helpful.
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):
No need to bisec, just stop when you see the pushlog.
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.
Yes, thanks, the 1st link is enough.
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.
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
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.
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)
(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.
(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
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
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.
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
(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.
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.
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.
Sorry is Apache 2.2
(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.
Please, no advocacy in the bug report.
(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.
Hello, we meet the same issue in our website.
It was worked perfectly until version 33 of Firefox.
Is a fix expected ?
Regards
this should be resolved by 1088850 in 33.1
Thank your for your answer.
Is there an ETA for this release ?
(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
Thank you.
I hope this release will fix our problem.
Have a good day!
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.
Patrick, I set this bug as fixed according to your comment #38, I think it's better for users hitting this issue than wontfix.
Depends on: 1088850
Resolution: WONTFIX → FIXED
Whiteboard: Fixed by bug 1088850
Sorry, but the bug isn't solved.
Please check:
http://www.infraroodwarmteshop.nl/attachment.php?id_attachment=80
(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.
(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.
I have applied version 33.1 of firefox on my computer and ... it works perfectly !
Thanks for the fix
Have a good day
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
(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.
you mean the websites where they occur? please let me know exactly what info or testing procedure you need.
Yes, post URL showing the issue up.
the first one was from https://online.americanexpress.com and the 2nd from https://www3.onlinecreditcenter6.com
We need the direct links to the PDF documents, if they are public.
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
but these require login as they are invoices.
So they aren't public. :/
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.

Attachment

General

Creator:
Created:
Updated:
Size: