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)
Core Graveyard
File Handling
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: robart, Assigned: neeti)
References
()
Details
Crash mozilla instead of show me a download dialog box.
Comment 1•24 years ago
|
||
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.
Comment 2•24 years ago
|
||
no problems here on 121112 mozilla win32 build on NT.
Comment 3•24 years ago
|
||
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
Comment 4•23 years ago
|
||
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 → ---
Comment 5•23 years ago
|
||
--> 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
Comment 6•23 years ago
|
||
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
Comment 10•23 years ago
|
||
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.
Comment 11•23 years ago
|
||
the server appears to have been at fault here and the link is still down
marking INVALID
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → INVALID
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•