Distilled from beta feedback: news://news.mcom.com/200106261925.PAA18415@home-s45.websys.aol.com Looking at the test case url above, the server is sending: Content-disposition: attachment; filename=net2phone106.exe When we bring up the save-as dialog box, we get the filename correct, but the filter is incorrect - it displays .cgi, but it should be displaying .exe I tried to poke through lxr to find cvs blame, and I think darin gets it. It looks like nsExternalAppHandler::PromptForSaveToFile is using mTempFileExtension, which is presumably wrong - at a guess, the content-disposition stuff needs to update this. Verified on trunk mozilla on linux, and this mornings comm bits on windows.

->mscott, after discussion with darin. I misread the cvs blame

accepting. I just posted the fix.

Quick turnarround :) Notes: - The first bit of the patch seems unrelated. - We'll still use the url name for the extention of the temp file, won't we? Not that it matters, I suppose. + fileExt = mTempFileExtension.ToNewUnicode(); leaks, since nsAutoString::operator = does a copy.

See also bug 31519, "Save as: should add extension to match content type".

this was checked in with my changes to 88066 last night. Thanks for catching the memory leak.

-> xp gui