The default bug view has changed. See this FAQ.

File dialogs don't open when SeaMonkey and Firefox are run with Visual Themes disabled in Windows 7

RESOLVED FIXED in mozilla16

Status

()

Core
Widget: Win32
--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: entonio, Assigned: bbondy)

Tracking

12 Branch
mozilla16
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

5 years ago
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.
Severity: normal → major
(Reporter)

Comment 2

5 years ago
OBS: This happened simultaneously in my work and home computer, with the 2.8 update. Both are Windows 7 x64.

Comment 3

5 years ago
This probably won't help but try downloading the SeaMonkey 2.9.1 installer from:
<http://www.seamonkey-project.org/releases/>
and then reinstalling.
(Reporter)

Comment 4

5 years ago
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.

Comment 5

5 years ago
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.
Summary: File dialogs don't open → File dialogs don't open when SeaMonkey is run with Visual Themes disabled in Windows 7

Comment 6

5 years ago
Confirm also happens with Firefox 12.
Status: UNCONFIRMED → NEW
Component: OS Integration → Widget: Win32
Ever confirmed: true
Product: SeaMonkey → Core
QA Contact: os-integration → win32
Summary: File dialogs don't open when SeaMonkey is run with Visual Themes disabled in Windows 7 → File dialogs don't open when SeaMonkey and Firefox is run with Visual Themes disabled in Windows 7
Version: SeaMonkey 2.9 Branch → 12 Branch

Updated

5 years ago
Summary: File dialogs don't open when SeaMonkey and Firefox is run with Visual Themes disabled in Windows 7 → File dialogs don't open when SeaMonkey and Firefox are run with Visual Themes disabled in Windows 7
(Reporter)

Comment 7

5 years ago
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.

Comment 8

5 years ago
Kyle Huey suggests I CC :bbondy and :jimm
(Assignee)

Comment 9

5 years ago
I'll take a look tomorrow.
Assignee: nobody → netzen
(Assignee)

Comment 10

5 years ago
Created attachment 638648 [details] [diff] [review]
Patch v1.
Attachment #638648 - Flags: review?(jmathies)

Comment 11

5 years ago
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.
(Assignee)

Comment 12

5 years ago
Created attachment 638708 [details] [diff] [review]
Patch v2.

Thanks for the review, good catch!
Attachment #638648 - Attachment is obsolete: true
Attachment #638648 - Flags: review?(jmathies)
Attachment #638708 - Flags: review?(jmathies)

Updated

5 years ago
Attachment #638708 - Flags: review?(jmathies) → review+
(Assignee)

Comment 13

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/9015f41f5e4e
Target Milestone: --- → mozilla16
https://hg.mozilla.org/mozilla-central/rev/9015f41f5e4e
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 15

5 years ago
Thank you Brian!
You need to log in before you can comment on or make changes to this bug.