User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 When i do a "file/save as" of the following page http://trimpath.com/demos/nextaction_static1/nextaction.htm on my USB 2 thumbdrive, it takes 21 seconds (option Web Page, Complete) during which the thumbdrive activity light is flashing like crazy. If i use the html only option it takes only 2 secs. If i use a text editor to save the same file it also takes 2 secs. As the content of the xxxx_files folder is very small (146k) i would expect the time to save the file with the complete option to be about 3 seconds. I am fairly confident that the usb drive is ok (for instance it takes 8.5 seconds to transfer a 27 M° file). If i make the same "file/save as" to a HDD, it is instantaneous. If i make the same "file/save as" to a SATA drive, it is instantaneous. If i make the same "file/save as" to a mapped HDD, it takes 1 sec. Reproducible: Always Steps to Reproduce: 1.load page http://trimpath.com/demos/nextaction_static1/nextaction.htm 2.start timer 3.do a file/save as to a usb thumbdrive 4.stop timer when firefox is active again (no more hourglass) Actual Results: it takes 21 seconds to make the save during which time firefox is completely blocked (hourglass) Expected Results: it should take 3 seconds Don't hesitate to contact me if you want me to make additional testing, i can't debug the code but i can test ;=)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050803 Firefox/1.0+ ID:2005080310 WFM <.5 secs this is fixed in deer park

i just tested with deer park beta 2, same result if not worse ...

11 seconds on a USB 1.1. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803 Firefox/1.0+ ID:2005080312

I have confirmed the problem on another USB pen (a USB 1). I have the same problem with both my home PC and my work PC. They are both XP/SP2 + firefox 1.0.6. I also add that the "optimize for performance" policy in the removable hardware preference tab of XP has no effect. Anyway, I have found a workaround for this bug, i have converted my usb pen to ntfs and the problem disappeared. SO there is definitely something weird with the way firefox and xp manage the cache writing.

Workaround: A tip I just read somewhere said to clear your download history. You can get there with control+J, and there's a convenient button to clear the history. (I forget who/what should get credit because I got there from Digg.) When I clicked the button, it hung both Firefox and my entiire machine, but when it finally got done, save-as complete took a reasonable amount of time. I assume that I should do this procedure often if I want save-as to be useful I'm surprised that this bug is "only" 8 months old because I'm sure that I've been avoiding FF for much longer than that because save-as was broken and unusable. I'm saddened because this bug has no one working on it, that a feature whose use I don't see a use for is blocking a feature I want to use, and that two features could be so incompatible in a piece of software that's been around so long.

When I try to save web pages all firefox windows freeze (this not happen on Internet explorer)

To make an accurate assessment it STM you need to remove variability and test the component operations - i.e. save complete to HD and then measure the FIRST copy of nextaction.htm+nextaction(directory) from HD to USB. And then measure save complete to USB using nextaction.htm loaded from HD. So with reference to reporter only - save complete to a HD takes a second or two. copying those files with windows explorer from HD to a USB drive, FAT formatted, took me ~5 seconds or more. Putting those measurements together there is no way a save to USB can be as fast as the 3 seconds you expect. Add in variability for your internet connection and you are easily in the 10-15 second range or higher. My save times using nextaction.htm loaded from HD were approximately the same using internet URL. >As the content of the xxxx_files folder is very small (146k) i would expect the >time to save the file with the complete option to be about 3 seconds. yes, if it were just a file copy, which this is not. When the page is loaded the page contents are retrieve "over the wire" to a large extent in parallel, not serially. But when you save the page I have not doubt the process is serial, i.e. slower. Add a slow USB drive to a serial process and yes, you will see something slow. Try saving it to a diskette to see what REALLY slow is. -> INVALID, USB interraction is not a bug I tested with USB2 and drive that is probably USB2 (not sure). USB 1.1 would obviously be much slower. FF and Seamonkey results are ~ same, I tested with FF trunk and SM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070109 SeaMonkey/1.5a with reference to comment 1, I don't know what patch or bug Peter is referring to, and perhaps something was improved with a patch at some point. If anything, non-USB aspects of this are related to bug 120809, bug 40867, and bug 115174 to name a few.

>> When the page is loaded the page contents are retrieve "over the wire" to a large extent in parallel, not serially. But when you save the page I have not doubt the process is serial, i.e. slower. Why does the page need to be re-retrieved from the internet when it is saved? Although I compare saves to disk, K-Meleon is much faster (nearly instantaneous) - maybe because it doesn't need to re-retrieve the page.

hmm, read the other bugs

see also - bug 487375 for more info about USB performance - bug 392728 about impact of RDF

Status... RESOLVED??? INVALID???... Is not resolved. Firefox 3.1b3 still have that problem. Any version from 1 up to date had that bug. Is not a Windows driver problem. Other browsers save pages just fine in the exact same USB pen drives. Is not an USB bug. Is Firefox bug.

I'm certainly not an expert, and my analysis was a 2 years ago so the memory is faded. But if I recall correct, USB's performance characteristics (latency, etc) are exacerbated by poor general performance of Save As (bug 120809) - cited in comment 7, which is worth reading carefully. And expectations of the reporter of this bug were/are certainly not realistic based upon that analysis, hence my closing it. Perhaps the effects of bug 120809 or others are even worse with DL manager. Perhaps Bug 441869 is valid on it's own. Can't say with 100% certainty without additional QA. And you state a) "I had find this bug in more than 100 computers running Windows 9x, XP or Vista, with 5 pen drive models (any tested), and Firefox 1, 2, and 3. I never found an exception." b) it doesn't happen on linux c) it doesn't happen on windows with other browsers So let's reopen, assume it is at least in part dependent on bug 120809, nd put it in component file handling so we get more/better eyes on the problem. And to start, it would help if someone tests and stated real performance numbers for a, b and c above.

I restrained myself from citing this 2 years ago, but see also Bug 198061 - downloading / saving to floppy causes unresponsive UI

I had just tested this again: Firefox 3.1b3, on windows XP sp3 Saving www.nytimes.com, to USB2 pen drive, froozed firefox for 10 seconds. saving to hard disk, froozed 1 second. There is no reason to have Firefox frozen only because a file is being saved.

Guillermo wrote: I tried to save www.nytimes.com using Firefox 10.0.2 both on HD and on USB pendrive. Obviously USB was lower than HD, but seems not to take so long as I remember. I don't know if it was fixed, or now I just have faster USB hardware. Anyways, entire Firefox remains non usable meanwhile saving the page. So I still consider an important issue, because lots of people in the world, pay per time using Internet, and save web pages to be read offline. Also, investigators frequently save pages, and time waiting for pages saved adds to time unproductive. Saving pages should be made in parallel, like downloading files. It should not block the use of Firefox.

duping forward to bug 623866. If problem not resolved when bug 623866 is fixed, then please reopen