Closed Bug 306380 Opened 19 years ago Closed 10 years ago

Hangs when trying to download a file from a badly configured webserver (i.e. tries to parse the file)

Categories

(Camino Graveyard :: Downloading, defect, P2)

Product:
Camino Graveyard
Component:
Downloading
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jann_roeder, Unassigned)

References

(
URL
)

Details

(Keywords: hang) 

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050829 Camino/0.9a2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050829 Camino/0.9a2+

When the mimetype of a file which is ment to be saved to disk is set to
text/plain or something camino tries to display the file in the window.

Reproducible: Always

Steps to Reproduce:
1. Click on the supplied link

Actual Results:  
Camino hangs (probably until it has downloaded the entire file)

Expected Results:  
It should be possible to cancel the action by clicking the stop or back button,
or any other button that makes camino load another page.
The display isn't a bug. Camino was told by the server that it should display
the file -- that's a server misconfiguration, and any properly coded browser
should have the same problem.

The fact that we don't do a great job of multitasking whilst downloading a huge
DMG file with an improper MIME type is an issue, however. Very likely a dupe,
though I don't know which bug. I know I've seen complaints about this before,
and I've run into the same annoying behaviour myself.

cl
A quick search of Core:Networking didn't turn up any active bug related to why
we essentially hang in this situation and can't cancel (well, we can
cancel--after nearly the entire file is displayed).

Does DeerPark also become unresponsive in this situation?
Firefox 1.06 allows the user to cancel loading. (After being unresponsive for
about two seconds)
(In reply to comment #3)
> Firefox 1.06 allows the user to cancel loading. (After being unresponsive for
> about two seconds)

What about a DeerPark branch build?

This does sound Camino-specific at this point, however.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Same issue occurs when downloading .dmg files from SourceForge, referred by the
VersionTracker website.
Since Camino is so slow to load and display large text/plain text or binary
files, we should offer an option to download the file.

Like this:
The user request to load anything that's text/plain. If camino finds out that
the file is larger than X MB (0.5 or 1.0 is perhaps appropriate), it will ask
you "Do you really want to view file $FILE?" with View/Download/Cancel.

The idea is to make a general solution that applies to any case of a huge file
being displayed. We would for example catch these dmgs, gzips and the occational
very large text/text data files.

Would it work and is it a good solution? Perhps this should be implemented from
gecko, but the dialog wouldn't look as good.
There probably is a way to catch the timeout within gecko, but the dialog would
of course not be written in gecko, but embedded with cocoa widget.
Sounds good, but will it also work for servers that don't supply the filesize ?
I think this is the case for the supplied link (The mono installer).
(In reply to comment #4)
> (In reply to comment #3)
> > Firefox 1.06 allows the user to cancel loading. (After being unresponsive for
> > about two seconds)
> 
> What about a DeerPark branch build?
> 
> This does sound Camino-specific at this point, however.

I just tried this in a Fx 1.8-branch build, and there's a much longer delay (ca
1.0-15 seconds), but still nowhere near as bad as Camino.

The server in question does send a content-length header, so I think comment 6
would work here.  I'd definitely set the threshold pretty low--0.5MB at the
*high* end--because anything over a couple hundred KB can hang Camino for a
while with a fast connection, and I shudder to think what even that small of a
file would do to dial-up folks.

In a perfect world this would be something in a 1.0 product, but I think it's
probably too much work for that and might require some Gecko/Necko changes
(Nick?), so putting it on the 1.1 list.
Target Milestone: --- → Camino1.1
Interested parties should also watch bug 261263.  Apparently the Core is
secretly doing sniffing of unconfigured servers sending the default header
("text/plain; charset=ISO-8859-1") before rendering, but not of "text/plain;
charset=UTF-8", which seems to be the new Apache default for unconfigured
servers--including the one in this bug.
[11:51pm] Mano: notices Camino still uses HEAD on "Download Link"
[11:53pm] cl: ?
[11:53pm] smokey: ?
[11:55pm] Mano: like, poke the server for some details before the download is initialized.
[11:55pm] smokey: ah
[11:56pm] Mano: (Content-Disposition headers for example)
[11:57pm] Mano: that might cause non-responsive UI issues

Not sure if that issue is relevant to the "hang" in this bug or if it's a separate bug we need to open (maybe it's the delay before the "save" dialogue appears?)....
kreeger, have you had a chance to look at this?  This is really awful user experience that it would be good to improve upon, even a little for 1.1
Assignee: mikepinkerton → nobody
Keywords: hang
Priority: -- → P2
QA Contact: downloading
Target Milestone: Camino1.1 → Camino1.2
Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
Bug 394647 probably helps out some here (i.e., comment 10).
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.