Closed Bug 62465 Opened 24 years ago Closed 23 years ago

Helper app dialog doesn't appear for .wad file

Categories

(Core Graveyard :: File Handling, defect, P3)

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: robart, Assigned: neeti)

References

()

Details

Crash mozilla instead of show me a download dialog box.
what build are you using? I can't repro the crash, but do see a issue on win98 2000120720 - the fotns in the ui get fucked. Interestingly enough, also in windows. in the start menu, the arros become '8' 's.
no problems here on 121112 mozilla win32 build on NT.
No Longer there.. Since worked for Asa I am marking it as Worksforme. reopen if its still a problem in the latest nightlies.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
I don't see a crash, but Mozilla doesn't offer to download it either; it displays it inline. Is the server claiming the wrong mime type? --> helper apps/law
Status: RESOLVED → UNCONFIRMED
Component: Browser-General → XP Apps: GUI Features
QA Contact: doronr → sairuh
Resolution: WORKSFORME → ---
--> law, I'm guessing the site needs evangelism though.
Assignee: asa → law
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: gfx.wad, crash mozilla → Helper app dialog doesn't appear for file
yep, see this on linux and mac, as well as winnt [2001.06.07.1x comm branch bits]. bill/mscott, do either of you know why the download/helper app dialog is not appearing here?
Blocks: 78106
OS: Windows 2000 → All
Hardware: PC → All
Summary: Helper app dialog doesn't appear for file → Helper app dialog doesn't appear for .wad file
The server is probably telling us the content-type is text/plain or some such and we believe them. And/or, the content-sniffing we do now is different than 4.x or IE do.
Here's the headers for http://quakeworld.free.fr/files/quake/gfx.wad (they seemed to have moved a little): HTTP/1.1 200 OK Date: Wed, 26 Sep 2001 00:56:41 GMT Server: Apache/1.3.12 (Unix) Debian/GNU mod_perl/1.24 Last-Modified: Wed, 19 Sep 2001 11:56:48 GMT ETag: "1018d86-1b8bc-3ba88800" Accept-Ranges: bytes Content-Length: 112828 Connection: close Content-Type: text/plain We're displaying plain text. It is likely that IE and 4.x actually looked a bit at the data to verify that it's ascii (or close to it). We could do likewise and when that check fails, look up the content-type based on extension. That has to happen in Necko and/or the uriloader. Retting component and reassigning.
Assignee: law → neeti
Component: XP Apps: GUI Features → Networking
QA Contact: sairuh → benc
cc'ing darin
the link appears invalid.. server says "Not Found" despite that, i think this is probably a case of WONTFIX that should be sent over to evangelism... if the web site tells us that the document is text/plain, then we are going to treat it as text/plain... this is exactly the purpose of the Content-Type header... IMO we should trust what the server says.
the server appears to have been at fault here and the link is still down marking INVALID
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → INVALID
Component: Networking → File Handling
QA Contact: benc → petersen
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.