Closed Bug 229787 Opened 22 years ago Closed 21 years ago

Downloading PDF file defaults to HTML extension and resulting file won't open in acrobat

Categories

(Core Graveyard :: File Handling, defect)

x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mark-graber, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Tried to download multiple PDF files from www.bmj.com. The extension defaults to html even though they are PDF files. It works fine in Opera. Didn't try IE Reproducible: Always Steps to Reproduce: 1.Search for a topic (I searched for tranferrin receptor) 2. Click to get the PDF file 3.The dialogue opens but has HTM (or HTML, I don't recall) as the default file name even though it is a PDF it is downloading 4. Resulting file won't open with acrobat Great product!
ironically, timeless had me checking something on this site earlier, and it is WFM.
also, unless you're saying the file is somehow corrupted as a result of this, renaming the file should work fine. Please test with a current build from the following directory as the download manager has received its second major upgrade in the 0.8 cycle. http://ftp.mozilla.org/pub/mozilla.org/firebird/nightly/latest-0.8/
Severity: critical → minor
Mark, can you give me a link to the exact PDF file that doesn't work? I tried searching how you specified but got no results.
From reporter: "The file does end up corrupted. I have a bit more detail. If you try to save the file from firebird using the "save as" function,(after the plugin acrobat has opened it) the file is saved as a "complete web page". It is corrupted even if you rename it with a PDF extension. Acrobat tries to open it but says it is a corrupted file. If I save it through acrobat's save function, it save's OK. I am running the most recent testing release: 02-Jan-2004 18:59 6.2M (2004-01-02-16-0.8) Instructions to reproduce are below. Hope things are well and you had a good holiday. ps. What is WFM stand for? Mark To reproduce: http://content.nejm.org/cgi/search?searchterm=syncope&andorexactfulltext=and&sortspec=Score+desc+PUBDATE_SORTDATE+desc&excludeflag=TWEEK_element&where=fulltext&hits=20&fmonth=January&fyear=1994&tmonth=January&tyear=2004 Choose the first article by Kapoor Acrobat will open Save via firebird's "save as" function Try to open with acrobat. I would guess this works with any PDF file. Hope things are well. Mark " I need a login to reach that file. Can you provide one?
Saving PDF files using Firebird's "Save As" works for me in general. In the specific case stated in the original report I think I may know what's going on. On bmj.com when you do a search and have results that contain PDF links, the links are not to just a PDF File. It links to a page that has the PDF in a frame,with a sidebar in another frame. So if you do a "save link as" on that link, it will save it as a web page. Comment 4 implies however, that the reporter is also having problems with using Firebird's "Save As" after a pdf file is opened (in general). As stated in my first sentence this WFM, (noting, of course, that I have not tried the specific link provided as it requires registration). Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20040102 Firebird/0.7+
Clicking on the pdf link, opens the pdf in acrobat reader for me. Saving the pdf link, gives me a file with a html extension. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040209 Firefox/0.8 (MozJF)
F. Chen 2/22/2004 With Windows 2000, Build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Follow-up tests find the problem is not so harmful. 1. Go to site http://bmj.bmjjournals.com/cgi/reprint/328/7436/0 with Mozilla Firebird browser 2. Right click “Begin manual download” and choose “Save Link to Disk” 3. Notice the default “Save as Type” is “Web Page, HTML only”, but the file name is still shown as "0.pdf" 4. Click “Save” 5. Notice the file downloaded is saved as "0.pdf" and Adobe Acrobat Reader 5.0+ opens it with no problem. Also, perform the same steps above on IE. In step 3, the default is “Adobe Acrobat Document” and the file name is still shown as “0.pdf”. In step 5, The saved file is also 0.pdf and has no problem to be opened by Adobe Acrobat Reader 5.0+.
Same thing happens on Seamonkey. Off to Browser. The PDF file is being sent as text/html, which explains why it's trying to save it as an HTML file, but technically it shouldn't be opening it as a PDF in the browser.
Assignee: bugs → general
Status: UNCONFIRMED → NEW
Component: Downloading → Browser-General
Ever confirmed: true
Product: Firefox → Browser
QA Contact: general
Version: unspecified → Trunk
why is this a browser bug? $> HEAD http://bmj.bmjjournals.com/cgi/reprint/328/7436/0.pdf 200 OK Connection: close Date: Mon, 23 Feb 2004 05:09:47 GMT Server: Apache/1.3.26 (Unix) ApacheJServ/1.1.2 Content-Length: 0 Content-Type: text/html Client-Date: Mon, 23 Feb 2004 05:11:42 GMT Client-Response-Num: 1
Assignee: general → english-other
Component: Browser-General → English Other
Product: Browser → Tech Evangelism
QA Contact: general → english-other
Version: Trunk → unspecified
timeless, if the file is being sent as text/html, why does it display in the browser as a PDF?
filehandling or something probably looked at the "text/html" and decided it wasn't and marked it as candidate for sniffing.
back to file handling, although this is probably a duplicate The site responds to the HEAD request with "Content-Type: text/html", but responds to a GET with application/pdf. so "save target as" will see text/html and append a .htm to the filename.
Assignee: english-other → file-handling
Component: English Other → File Handling
Depends on: 160454
Product: Tech Evangelism → Browser
QA Contact: english-other → ian
Whiteboard: DUPEME
Version: unspecified → Trunk
Save Target As does a HEAD first?
Yes, to get the type and Content-Disposition filename. Unfortunately, this causes more problems than it solves.
*** Bug 260038 has been marked as a duplicate of this bug. ***
Bug 160454 has been fixed, and this is still a problem. Removing dependency.
No longer depends on: 160454
Jason, I assume you tested a trunk SeaMonkey build?
Boris, I tried a fresh Seamonkey trunk build but it crashed when I tried to save the PDF. I did try a fresh Firefox trunk build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041016 Firefox/0.9.1+). I assumed that Firefox and Seamonkey have common file handling code. Am I wrong?
> I assumed that Firefox and Seamonkey have common file handling code. Am I > wrong? Yes, you're wrong. Firefox forked almost all of file-handling very long ago; bug 160454 will need to be fixed separately for Firefox. Putting the dependency back pending testing in a SeaMonkey build.
Depends on: 160454
Boris, for future reference, is there anything that lists which components Seamonkey and Firefox don't share?
Unfortunately, no. And every so often I discover yet another thing that Firefox forked...
When I do a "Save Link Target As.." in a 2004-10-07 build, I get a .htm extension in the file picker. But in a 2004-10-18 build I get the desired .pdf extension (with the right filetype). I'm marking this FIXED. If someone can still reproduce this bug in Seamonkey build later than 2004-10-10, then please reopen.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
(In reply to comment #22) > When I do a "Save Link Target As.." in a 2004-10-07 build, I get a .htm > extension in the file picker. > But in a 2004-10-18 build I get the desired .pdf extension (with the right > filetype). > > I'm marking this FIXED. If someone can still reproduce this bug in Seamonkey > build later than 2004-10-10, then please reopen. > I can't confirm or deny the existance of this bug, but - what happens if, instead of Saving the link target via the context menu, you just left-click the pdf link?
(In reply to comment #22) > I'm marking this FIXED. Are we marking bugs that were fixed by a patch to another bug as FIXED now? Wouldn't a better resolution to be mark as a duplicate of bug 160454, since that's where the patch is?
> Are we marking bugs that were fixed by a patch to another bug as FIXED now? Yes. > Wouldn't a better resolution to be mark as a duplicate of bug 160454 No, because it's not a duplicate. It's a dependency. There is a difference.
Whiteboard: DUPEME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.