I stumbled across this when attempting to write drag & drop support for a file. Easy test: execute this in the Error Console for an crash: Components.classes["@mozilla.org/mime;1"].getService(Components.interfaces.nsIMIMEService).getTypeFromURI(null); 3.6.13 on Windows: bp-3cc36a71-f34d-4ebe-ac6f-b7d502110210 3.6.13 on Linux: bp-29bd2e99-cddc-43c0-81fe-7a50d2110210 4.0b12pre on Linux: bp-915d00df-c282-42b0-a675-92edb2110210 http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/0c159bd1d600/uriloader/exthandler/nsExternalHelperAppService.cpp#l2693 Looks like it just needs a null check for aURI up top.
getTypeFromFile also crashes -> filed bug 633240
Not a candidate for blocking, as far as I can tell. It's been this way since at least Firefox 3.0 and I don't see a way to get at this from the web, though if anyone else does please say so. Requesting wanted+ for all affected branches.
Created attachment 515545 [details] [diff] [review] patch
6 years ago
These two crash bugs (bug 633232 & bug 633240) have reviewed one-line patches. Any reason they can't land now? They should at least be able to land on Trunk at this point, I would think. Could they also make Firefox 4.0.1 too?
How can this be tested? thanks.
(In reply to comment #6) > How can this be tested? These two bugs (bug 633232 & bug 633240) both have the necessary one line tests in their descriptions. Just run that one line anywhere with chrome privileges. The lazy test is to dump it into the Error Console code evaluation field, but a proper test could be written to run it if desired. When either is run on anything prior to the fix landing in Gecko 6 it crashes and with the fix it throws an invalid pointer exception as one would expect.