User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Mozilla Firefox 3.0b3 crashes after attempting to change settings in the 'MAIN' tab. This error occurs only if you automatically save downloads to your computer, and the directory or drive of that location does not exist. For example, you set Firefox to automatically save downloads to 'Drive J:', but you remove that drive. If you attempt to change the settings, Firefox will crash. Reproducible: Always Steps to Reproduce: 1. Insert any removable drive. You can also select another Partition on your hard drive. Note the drive Letter. 2. In Firefox, go to Tools > Options > Main Tab 3. Choose 'Save Files to:' and Select the Drive Letter noted in Step One. Close Options. Close Firefox 4. Unplug or remove the removable drive in step one. If you chose a partition, remove the drive letter. 5. Run Firefox. Go to Tools > Options > Main Tab. 6. Firefox will have crashed. It will prompt you to restart Actual Results: Firefox crashes Expected Results: You should be able to change options as usual

Please don't cc the world on a bug just because.

The regression range doesn't seem to make much sense: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1187223060&maxdate=1187224079

http://crash-stats.mozilla.com/report/index/5c4487ee-e334-11dc-bbdf-001a4bd43ef6 http://crash-stats.mozilla.com/report/index/5596a559-e334-11dc-81a7-001a4bd43e5c

Hm, maybe someone else has better crash reports. Always trouble with this computer.

My crash report came out the same as your Ria.

The crash seems to be an assert within the crt

We have a bug filed on breakpad to report these more effectively, it's probably the "invalid parameter handler" in the CRT, which gets called when you pass a bad parameter to a CRT method. We do get some extra assertion info in the crash report that we're not currently reporting.

Suggest low priority blocker for now, as I don't think this is a very common use case. I'd look into timeout problems, maybe, as Windows can take a REALLY long time to return the file chooser here. --> Core::

I tested this with a simple USB stick, something that I use every day to transport data to another computer. The user might not understand that plugging in that thing is the only way to stop the crashes.

this isn't really a regression, it's a feature of moving to msvcrt8. http://msdn2.microsoft.com/en-us/library/7t2zk3s4.aspx

Here's a real simple testcase: z=Components.Constructor("@mozilla.org/file/local;1","nsILocalFile","initWithPath")("z:.\\test"); z.normalize(); This crashes without this patch, and throws with it. (I don't have a Z drive, which is the point.) Ideally we'd have a crashtest that iterated through A..Z and did this for each one.

Also, this might still break stuff (some JS somewhere might need to catch this exception), but it will prevent the crash.

Comment on attachment 306132 [details] [diff] [review] throw... reviews before approval requests, please! this won't block beta 4

Comment on attachment 306132 [details] [diff] [review] throw... unit-test please!

Comment on attachment 306132 [details] [diff] [review] throw... mozilla/xpcom/io/nsLocalFileWin.cpp 1.183

Comment on attachment 307399 [details] [diff] [review] . mozilla/xpcom/tests/unit/test_localfile.js 1.2