User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Some pages (like url in example; click download) do not send correct headers, so that firefox starts to parse it like a website. This couses firefox to become non-responsable after it tries to parse files bigger than a couple of MB's. Reproducible: Always Steps to Reproduce: 1. Visit website that has download link 2. Download should not say it's a download in the header (like on http://www.springyarchiver.com/download.php click download) 3. Firefox will show content of the file, but will start being non-responsable Actual Results: Have to terminate firefox the hard way Expected Results: Maybe error like 'Sorry, page is to big. Click here to download if it was a download-able file' or at least be responsable. Maybe good to be able to set a maximum to MB's that firefox will parse. Like pages normally on the internet will never be bigger then 1MB, so why try parsing it.

This is not critical --> normal If the server is sending the wrong mimetype, then yes, firefox will process it as such.

stevee must have missed the part of this bug report that says it causes Firefox to hang...

yes, stevee doesn't know what he was thinking and is now appropriately red-faced with embarrassment. Sorry will-i-am!

Is this better or worse on trunk? The font selection and text rendering code has been more or less rewritten since Firefox 2.0.0.x, and layout code has changed quite a bit as well. See also bug 367116, a hang with a 20MB mbox text file. If trunk is still slow with text/plain binary files, I wonder whether it's for the same reason that it's slow with text/plain text files.

1. New profile, start firefox 2. Go to http://www.springyarchiver.com/download.php 3. Click on the Springy 1.3 (6.1MB) image. With Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.6pre) Gecko/2007072403 BonEcho/2.0.0.6pre firefox hangs. With Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a7pre) Gecko/2007072905 Minefield/3.0a7pre ID:2007072905 I actually crash. (No breakpad on win2k, so no idea where or why)

Crashes on Mac trunk too. I get tons of gfxFont.cpp assertions, a double-free warning from malloc, and a crash [@ gfxTextRun::CompressedGlyph::IsClusterStart]. The crash is probably bug 389428.

The trunk crash occurs on Linux too. Bug 389428 fixes the crash, but the performance is still bad and lots of text frame assertions in a debug build.

Should retest once bug 389428 lands. Probably file a separate bug on the asserts, then profile once those get fixed...

I still get lots of gfxFont.cpp assertions and "Deallocation of a pointer not malloced: 0xfefefeff". I'm guessing that's covered by bug 385289, bug 385719, and/or bug 388367.

I get a hang, with lots of copies of this assertion: ###!!! ASSERTION: Started word in the middle of a cluster...: 'aSource->IsClusterStart(start)', file /scratch/work/builds/trunk.07-09-11.17-34/mozilla/gfx/thebes/src/gfxFont.cpp, line 1683 I didn't see the "deallocation of a pointer not malloced" warning, so that part may have been fixed.

I just ran into this when a spammer posted a binary attachment to bug 69230 (150KB .BMP). Viewing the attachment details caused my trunk nightly to hang for a couple minutes (beachball, 100% CPU), but eventually rendered the gibberish text. Annoyingly, if you switched to another tab or window and returned, the process would repeat (ugh!). And when I clicked the "submit" button to change the attachment details, I was treated to the hang again.

Oh, adding regression keyword as Reed reported that it worked fine on FF2/Linux, with no slowdown.

So... Trying to make a 6MB file not hang is a LOT harder than making a 150KB file not hang. Removing regression keyword, since this bug is reported against Fx2. We should get a new bug filed on the testcase mentioned in comment 12, since that sounds like a very different problem.

I filed bug 396726 on the Linux aspect of comment 12 and bug 396732 on the Mac stuff. As expected, the two had very different problems; someone with access to Windows should test and see whether we need another bug.

(In reply to comment #6) > 1. New profile, start firefox > 2. Go to http://www.springyarchiver.com/download.php > 3. Click on the Springy 1.3 (6.1MB) image. Looks like that site's fixed their mimetype issue -- now I get a "Save file" download manager popup when I click on the Springy image.

Can we just stash that file somewhere stable with a .txt extension and point to it? It's too bad it's too big to attach to bugzilla... :(

I tried (http://www.squarefree.com/bug390051/) but Firefox prompts me to save the dmg rather than trying to display it as text. When this bug was reported, the current version of Springy was 1.3, so the difference could be due to a change in the dmg file between 1.3 and 1.3.3. Is there a special mime type (or charset annotation) that I can use to force it to display as plain text?

"text/plain; charset=us-ascii" should do the trick.

Thanks, that does indeed do the trick. Do you get a hang with http://www.squarefree.com/bug390051/Springy%201.3.3.dmg.uat ?

No hang that I can see; just takes a while to load. No assertions either.

> No assertions either. We went through the process of watching assertions in "binary as text/plain" go away in bug 390032 :)

So this is fixed on trunk I guess. Will probably get better again when jdaggett's Mac font selection work lands. Leaving open for branch although it won't get fixed there, I'm pretty sure.

Marking fixed actually. If we need a bug for branch, someone should file one, although personally I'm pretty sure we won't fix branch so there's no point in filing a bug.