Our intranet web application is providing PDF files for its users. PDF files are returned as inline content (for displaying inside browser window). Since Firefox 184.108.40.206 release users has not been able to display PDF files from application inside browser window. Tab with PDF has "(application/pdf object)" title, but it doesn't refresh and display previous tab content or content of other tab window. PDF files found on Internet are normally displayed without problems. Maybe is important, that PDF is comming form SSL site with Cache-Control set to public. I'm CCing Boris (for bug 402649), Christian (for bug 345181) and Daniel (it's stable branch regression). I do apologize, if such CC'ing is inappropriate. Regression window on 1.8 branch: ... 2007111303 - ok 2007111404 - broken - fixes for bug 402649 and bug 402460 checked in on branch 2007111503 - broken 2007111504 - broken ... 20080228 - broken - 220.127.116.11pre Checkings in that time window (check parameters): http://tinyurl.com/24e3a6 Note: SeaMonkey 1.1.8 (18.104.22.168/20080201) has no problem with displaying PDF file. On trunk this bug was already fixed: ... 2007111104 - ok 2007111204 - broken - fixes for bug 402649 and bug 402460 checked in on trunk ... 2007113005 - broken 2007120105 - ok - fixes for bug 262116 and bug 345181 checked in ... Daniel's comment - bug 345181 comment #14 HTTP header of response: HTTP/1.x 200 OK Date: Fri, 29 Feb 2008 11:07:00 GMT Server: Apache/2.0.55 (Ubuntu) mod_jk2/2.0.4 PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a Expires: Sat, 28 Feb 2009 11:07:00 GMT Cache-Control: public, max-age=31536000 content-disposition: inline; filename="FEP08-2162 2008-02-06_15-30-47.pdf" Content-Type: application/pdf Content-Length: 6787 Keep-Alive: timeout=15, max=98 Connection: Keep-Alive All tested with Adobe Acrobat 8.1.0. I could provide PDF file or access to application for developer.
Plug-ins depend on being able to cache as file, iirc. That might be why the cache-control thing helped.... That said, I see no HTTP or plug-in changes in the original regression range, and I wouldn't have expected the window.location thing to affect this... Is your application doing something interesting from unload handlers? Do you hit the docshell code added in bug 402649? Sadly, I doubt I'll have time to debug this in time for 22.214.171.124. jst, do you think you could possibly take a look?
jst, see comment 1?
Setting "browser.cache.disk_cache_ssl" to "true" (as oposite for default "false") is workaround for this bug, so this is probably problem with caching files delivered via SSL. Moving bug to Networking. (In reply to comment #1) > That said, I see no HTTP or plug-in changes in the original regression range, I can't see any checking in regression window on branch, which could be related to caching SSL files. =( Maybe I set wrongly query on Bonsai... > and I wouldn't have expected the window.location thing to affect this... Is > your application doing something interesting from unload handlers? Do you hit > the docshell code added in bug 402649? PDF is delivered on direct URL: you send GET request and get PDF file as response, so probably answer is no. For second answer I don't know answer.
Just for info. With latest Firefox Trunk our application works fine but there was a problem too. I will try to find regression window and bug which fixed this problem on trunk.
Adam, can you do HTTP logs in the two branch nightlies (the one before the regression and the one after) and attach them here? Ideally, just start the browser with the URI of the PDF, wait for it to load, then quit, if that shows the bug. Make sure that during this test run one nightly shows the bug, and the other doesn't...
Found a similar issue with 126.96.36.199 today. We earlier used to have the URL executed on our own server and worked absolutely fine even in 188.8.131.52, but in the current scenario we are having a single sign on (SSO) webserver intercepting our request. This is breaking our functionality in 184.108.40.206 but surprisingly working fine in mozilla version 220.127.116.11 or below. Http Header values SUCCESS: POST /******/authreg/pdf HTTP/1.1 Host: **********.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20080201 Firefox/22.214.171.124 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: https://*******/portal/site/******/authreg/StatementsAndDocuments/ ****** Cookie: lastLogin=*****; HTTP/1.x 200 OK Date: Sat, 01 Mar 2008 11:38:52 GMT Server: IBM_HTTP_Server *********** Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/pdf Content-Language: en -------------------------------------------------------------------------------- FAILURE Cache-Control: no-cache Keep-Alive: timeout=15, max=94 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 Content-Language: en This also works on all versions of IE and other browsers. We just want to rule out any probability of our design changes in our application breaking the PDF rendering on Mozilla 126.96.36.199.
Comment 6 doesn't sound related to this bug, unless it used to work with earlier branch releases. I'd start by fixing your server to not claim that the PDF is text/html, for what it's worth.
Created attachment 307001 [details] livehttpheaders output of Gecko/20071113 and Gecko/20071114 (In reply to comment #5) > Adam, can you do HTTP logs in the two branch nightlies (the one before the Hope, that LiveHTTPHeaders output is enough.
It's not. I need to see details about whether we're hitting the cache, etc. There are instructions explaining how to get an HTTP log at http://www.mozilla.org/projects/netlib/http/http-debugging.html
Given the code freeze in a couple days I doubt we'll get a fix in time for 188.8.131.52 so "blocking" seems more faith-based than realistic. But if we _do_ get a patch please request approval. I'm not sure the mere headers are enough for debugging (same requests, same responses), actual logging will show more information like error states and such: http://www.mozilla.org/projects/netlib/http/http-debugging.html
Created attachment 307224 [details] HTTP log 1.8-20071113
Created attachment 307226 [details] HTTP log 1.8-20071114 Both logs were truncated little before request on PDF, so loading browser start-page and login to application is not included. Cache was cleared before logging.
Hmm. Nothing jumps out at me there. In comment 0, you said you might be able to give access for someone to debug. Can we do that?
OK. So I did a little more digging. Calling SetCacheAsFile() of course fails. So we end up under nsPluginStreamListenerPeer::SetupPluginCacheFile. This gets the plugin temp dir, and then uses CreateUnique in that dir. So I'll bet money this is a regression from bug
I meant "from bug 402460".
Loading PDF file from perspective of Windows TEMP directory: 1.8-20071113 c:\temp\plugtmp\ - created, empty c:\temp\plugtmp-1 - created, size of PDF file 1.8-20071114 c:\temp\plugtmp\ - created, empty c:\temp\plugtmp-1 - MISSING
Aha! So yeah, something is going wrong with CreateUnique, somehow.
Stupid Windows. If you try to create an existing directory you get ERROR_ALREADY_EXISTS, but if you try to create a file and a directory exists you get ERROR_ACCESS_DENIED, which is the same error that you get if no file exists but cannot be created.
Hrm... Shouldn't we be creating the file inside plugtmp?
OK, so it looks like different callers abuse CreateUnique in different ways; some callers, such as SafeOutputStream, want to create a backup file, which somewhat assumes that there is an original file, and don't mind failing if they can't back up a directory. Here however I guess we really want a temporary file, but we don't have an API for that, which is why we're faking it.
(In reply to comment #7) > Comment 6 doesn't sound related to this bug, unless it used to work with > earlier branch releases. I'd start by fixing your server to not claim that the > PDF is text/html, for what it's worth. > Boris, this was indeed working with earlier versions i.e 184.108.40.206 which I could test with. I Couldn't figure out why this is only failing in the current versions. I even tried with the latest nightly build (minefield), but was not successful. I cannot fix the text/html stuff because the intercepting server is owned by a third party.
Neil: are you still working on this one? the 220.127.116.11 code-freeze is coming soon so we need to know if that's a realistic expectation.
Sorry, I can't work out how to work around the bug without a test case.
Not going to be able to land bug 345181 in this release, -> 18.104.22.168
I filled bug 444345 for similar problem with PDF delivered with cache-control:private as regression since Firefox 3.0b2. Changing bug summary to better reflect what is know about this bug.
So we need a testcase for this. Is that simply a PDF on an SSL server with cache-control:public set?
Uh... Wouldn't a testcase just be the set of CreateUnique calls that happen here? That is, just an xpcshell test? If Neil means he needs to see what exactly the plug-in code is doing, all that's needed is a PDF file on an SSL server. That's enough for branch. For trunk it also must not be sending "Cache-control: public".
OK, scratch that. To get this bug to trigger we need to have a temp dir and be creating a temp _file_, right? I think the only way we can hit that is to have a URI with an empty leafName that comes back as a PDF (the URI in the HTTP log is just such a URI). So in addition to what I said in comment 27, the URI the PDF is coming from needs to be of the form https://some.host.here/some/path/ with nothing after the last slash. This shouldn't be hard to set up for someone with clue and access to a .htaccess file on a reasonable Apache install. Just create a directory, put a PDF named test.pdf in it (https://bugzilla.mozilla.org/attachment.cgi?id=334617 if you can't find one), put "DirectoryIndex test.pdf" in the .htaccess, and you should be set.
There's a testcase for this bug now at https://landfill.bugzilla.org/ryl/pdf-test/ or so I hope. I don't have a Windows machine to reproduce with offhand.
Neil, does that testcase help?
Changing testcase to https://ananke.softeu.cz/pdf/public/ - it contains in response cache-control property with right values: HTTP/1.x 200 OK Date: Thu, 21 Aug 2008 08:33:31 GMT Server: Apache X-Powered-By: PHP/4.3.10-19 Expires: Sat, 28 Feb 2009 11:07:00 GMT Cache-Control: public, max-age=31536000 content-disposition: inline; filename='public.pdf' Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 11929 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: application/pdf https://landfill.bugzilla.org/ryl/pdf-test/ is not correct testcase, I can't reproduce bug with Fx 22.214.171.124, because response doesn't contain cache-control property: HTTP/1.x 200 OK Date: Thu, 21 Aug 2008 08:31:36 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Wed, 20 Aug 2008 04:20:23 GMT Etag: "99542a-73b4-85e8afc0" Accept-Ranges: bytes Content-Length: 29620 Connection: close Content-Type: application/pdf X-Pad: avoid browser bug
(In reply to comment #19) > Hrm... Shouldn't we be creating the file inside plugtmp? Without a file name, we try to create the file next to plugtmp. Is there a particular need to use the URL's file name?
Created attachment 334857 [details] [diff] [review] Proposed patch This is a CVS patch because I was testing it on branch.
"Cache-control: public" shouldn't matter on branch, and makes the bug disappear on trunk, no? So why is that the correct thing for the testcase? Neil, I doubt it's that important to have the exact filename from the URI. But it still seems to me that there's a fundamental bug in CreateUnique here, where it will fail in some cases where it should succeed. Working around it in the plug-in code is fine, but we should fix XPCOM too, no?
Comment on attachment 334857 [details] [diff] [review] Proposed patch Looks like a good workaround, bug please file the XPCOM bug on this problem too.
Pushed changeset 3848ffd8a143 to mozilla-central. Leaving this bug open until branch checkins have landed. (In reply to comment #35) > please file the XPCOM bug on this problem too. Filed bug 452217 against XPCOM.
Comment on attachment 334857 [details] [diff] [review] Proposed patch Simple regression fix.
> Leaving this bug open until branch checkins have landed. Note that the bug probably needs to be resolved for the branch driver queries to properly pick up its state (fixed on trunk, etc).
OK, I'll mark this fixed, although trunk is actually tracked by bug 444345.
Comment on attachment 334857 [details] [diff] [review] Proposed patch Approved for 126.96.36.199 and 188.8.131.52, a=dveditz for release-drivers.
Fix checked in.
Verified FIXED. I can reproduce the bug with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/20080702 Firefox/220.127.116.11, but not with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20080829 Firefox/22.214.171.124, using https://ananke.softeu.cz/pdf/public/ as the testcase URL. Replacing fixed126.96.36.199 with verified188.8.131.52.
Stephen, can you verify this with the final 3.0.2 candidate build too?
(In reply to comment #43) > Stephen, can you verify this with the final 3.0.2 candidate build too? Verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/2008090514 Firefox/3.0.2. Replacing fixed220.127.116.11 keyword with verified18.104.22.168. Also, as Neil says in comment 39, trunk is covered by bug 444345, so also marking as Verified.