User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1 Build ID: 20120429011004 Steps to reproduce: Try to open a file or save a file or attachment. All such dialogs are affected, in the browser and in the mail client, including the 'Save All' for attachments. Saving without dialog, to a default location, works. The bug has happened at least since SM 2.8 on Windows 7 x64. It doesn't seem to happen on Mac OS X 10.6. Actual results: The dialog doesn't open. Nothing happens. Expected results: The dialog should open.
Tried using a new profile, same result. Tried using safe mode, same result. Tried disabling all extensions, same result. Tried everything together, same result. This had never happened prior to the update. Before the update I was running some 2.x version, I can't guarantee it was 2.7, but it must have been close.
OBS: This happened simultaneously in my work and home computer, with the 2.8 update. Both are Windows 7 x64.
This probably won't help but try downloading the SeaMonkey 2.9.1 installer from: <http://www.seamonkey-project.org/releases/> and then reinstalling.
Well! I tried using the 2.9.1 installer in my home computer (which still had 2.8) and nothing changed (thanks anyway). But that prompted me to look at the shortcut I was using, and in Properties\Comptibility I had, in times, selected 'Disable Visual Themes'. I tried unchecking that, and voila, the dialogs work if it is unchecked. Of course, they used to work before, with it checked. So... whatever the cause of this behaviour is, it may be traced to something having to do with the 'Compatibility - Disable Visual Themes' thing. It's a per-executable setting, iiuc.
Are you using a third party Windows 7 theme? Try going to Control Panel->Personalization and choose one of the Windows7 themes that came with the system.
Confirm also happens with Firefox 12.
My theme is the normal Aero one. I've tried disabling the theme altogether and got the same result: dialogs work if and only if the compatibility setting is unchecked. This behaviour happens from at least 2.8 on.
Kyle Huey suggests I CC :bbondy and :jimm
I'll take a look tomorrow.
Created attachment 638648 [details] [diff] [review] Patch v1.
Will canceling the dialog give us a false return here? http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsFilePicker.cpp#598 Maybe we should fall through only when CoCreateInstance fails.
Created attachment 638708 [details] [diff] [review] Patch v2. Thanks for the review, good catch!
Thank you Brian!