Same problem as bug 633232 with a different function. Easy test: execute this in the Error Console for an crash: Components.classes["@mozilla.org/mime;1"].getService(Components.interfaces.nsIMIMEService).getTypeFromFile(null); 3.6.13 on Windows: bp-7b7bd39c-4a4d-4964-85e7-3914f2110210 3.6.13 on Linux: bp-777ec39c-3ac5-414f-b4df-4f3832110210 4.0b12pre on Linux: bp-c35974d7-650e-4f32-996f-f1d592110210 http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/0c159bd1d600/uriloader/exthandler/nsExternalHelperAppService.cpp#l2721 Looks like it just needs a null check for aFile up top.
Component: General → File Handling
QA Contact: general → file-handling
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.
Assignee: nobody → timeless
Status: NEW → ASSIGNED
Attachment #515546 - Flags: review?(cbiesinger)
8 years ago
Attachment #515546 - Flags: review?(cbiesinger) → review+
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?
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Crash Signature: [@ nsExternalHelperAppService::GetTypeFromFile(nsIFile*, nsACString_internal&) ]
You need to log in before you can comment on or make changes to this bug.