nsIFileWidget is used in a number of places for opening/saving files. In the two cases that I've notice so far, there is absolutely no error checking to test whether the component manager actually managed to create a file widget. So the code looks like: nsIFileWidget* fileWidget; nsComponentManager::CreateInstance(kCFileWidgetCID, nsnull, kIFileWidgetIID, (void**)&fileWidget); fileWidget->SetFilterList(5, titles, filters); This is lack of error handling is appalling; in a componentized world such as ours, who knows what trivial user error could result in the component manager being unable to create an instance of something. Check return values, please!

If error-checking code isn't in the woods, and a call doesn't fail, does anybody not hear it? The code is broken; I'll fix it. But let the record show I didn't write the original version (I did copy the bad version into some of my code though, so I feel worse about that).

Rod, this appears to be your code ...

I copied the code from elsewhere also, and feel as bad a Bill.... I'll track down the origin and fix it, and promise to do a better job when copied other people's code. Bill, did you fix this or do you want me to?

I have fixed it, I check it in when the tree opens.

Added the error handle in OnSave(), and OpenWindow()

i did a search on the source tree and found two files that appeared to have said error checking updated -- (cvs version 1.89) nsBrowserAppCore.cpp line 1297 nsFileDownloadDialog::OnSave() nsBrowserAppCore.cpp line 1594 nsFileDownloadDialog::OpenWindow() marking verified

Reopening. The error handling (and leak removal) went in to OpenWindow(), but not into OnSave().

I guess that is a matter of opinion, I will change it to check the error code, but the current code checks to see if the filewidget is not null, so it is error checking and it is safe.

The OnSave method got removed by law.

so can i mark this bug VERIFIED?

Yes, you can mark this verified; the code mentioned here is obsolete.

thanks! VERIFIED it is.