If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

When installing extension, window close button disabled

RESOLVED FIXED

Status

()

Toolkit
Add-ons Manager
--
major
RESOLVED FIXED
14 years ago
9 years ago

People

(Reporter: jhp (no longer active), Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

({fixed-aviary1.0})

unspecified
PowerPC
Mac OS X
fixed-aviary1.0
Points:
---
Bug Flags:
blocking-aviary1.0 +
blocking-aviary1.0mac +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.13 KB, patch
Ben Goodger (use ben at mozilla dot org for email)
: review+
Ben Goodger (use ben at mozilla dot org for email)
: approval-aviary+
Details | Diff | Splinter Review
(Reporter)

Description

14 years ago
Downloaded 0.9rc and then went to install Chatzilla.  Hit "Install" in the
resulting window, which then brings up the extensions manager window.  This
shows the install progress for the extension.  The Close and Maximize buttons on
the window are disabled; only the Minimize button can be clicked.  As a work
around, though, you can still type Cmd-W to close the window, but it will
confuse users.

Afterwards, if I go to Tools->Extensions menu, all three window buttons are
enabled.  So it only seems to be a problem when installing an extension.
I'm seeing this with the Themes manager with 0.9 on OS X as well - there's no
way to close the Theme Manager window without closing the entire application.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 Firefox/0.9

I see this on Linux with GTK 1.2 and the Sawfish window manager. There is no
title bar at all, so the minimize, maximize, close buttons are missing.
Control-w works close it though. The bug applies to both Extension and Theme
managers.

Also, the dialogs are modal so that I can't use the browser for anything else
while a large theme is being downloaded. Perhaps this is the real issue here.

Updated

13 years ago
Flags: blocking1.0mac+
(Reporter)

Updated

13 years ago
Flags: blocking1.0?
(Reporter)

Comment 3

13 years ago
*** Bug 249170 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 4

13 years ago
Anyone have any ideas on this one? It's very odd to be forced to close the
window with the keyboard. Definitely shouldn't be in a 1.0 release. (This is on
Firefox 0.9.1 on OS X 10.3).

Comment 5

13 years ago
Another workaround is to already have the proper dialog open (via the Tools
menu) before installing the new extension or theme. In Linux, anyway.

Frankly, even having to use WM buttons to close dialogs is weird. They should
have Close buttons.

Comment 6

13 years ago
(In reply to comment #5)
> Another workaround is to already have the proper dialog open (via the Tools
> menu) before installing the new extension or theme. In Linux, anyway.
> 
> Frankly, even having to use WM buttons to close dialogs is weird. They should
> have Close buttons.

On OS X, if you have the proper dialog open, the window close button actually
changes state (from enabled to disabled) after the extension is installed; right
before your eyes. So whether it's opened before or not doesn't make a
difference. Also, on the Mac, the WM close button is a pretty standard way to
close windows, which is why I wish the find dialog had one, but that's Bug 162257 

Comment 7

13 years ago
*** Bug 252994 has been marked as a duplicate of this bug. ***

Comment 8

13 years ago
Same behaviour for me in trunk dated 2004-07-27.
Asa and I saw this bug today on the Mac. I was using 20040802 Firefox/0.9.3. Ben
mentioned this is also being seen on Windows, not just Linux and Mac. Can
someone confirm?
(Reporter)

Comment 10

13 years ago
When opening the Extensions window from Tools->Extensions, the window is opened
with the options "chrome,dialog=no,resizable".  When installing an extension,
the function nsXPInstallManager::OpenProgressDialog() is called, which opens the
Extensions window with the options "chrome,centerscreen,titlebar,resizable".  If
I make the following change, then the close box is properly enabled:

-  "chrome,centerscreen,titlebar,resizable",
+  "chrome,centerscreen,titlebar,dialog=no,resizable",

However, I'm not familiar with this code and don't know if this is an
appropriate change.

Comment 11

13 years ago
I really hate this bug; someone tell me the name of the xul file for this window
so I can post a patch.
Severity: normal → major
brade, not xul but cpp:
http://lxr.mozilla.org/aviarybranch/source/xpinstall/src/nsXPInstallManager.cpp#498
(Reporter)

Comment 13

13 years ago
Brade, see comment #10.  Is that the correct change to make?

Comment 14

13 years ago
I was hoping for the actual xul file name since I wanted to find the other
places (via lxr) that also open this xul file.  It opens fine except when
installing extensions.  If all the use the same flags, I'll be happy.  :-)

p.s. Comment 10 may be the correct fix; I would expect to see "close" in the
list but if that is the same as elsewhere it's fine.
(Reporter)

Comment 15

13 years ago
Created attachment 157169 [details] [diff] [review]
patch

Match window options in XPInstall to those in XUL.  Don't know if titlebar is
still needed, though.
(Reporter)

Updated

13 years ago
Attachment #157169 - Flags: review?(bugs)

Comment 16

13 years ago
Brade, the file name of the extension/theme manager is extensions.xul.

Comment 17

13 years ago
*** Bug 262768 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Blocks: 250514

Comment 18

13 years ago
I've seen this bug in the version 1.0 Preview Release's Themes installer too.
Command+W closes the dialog as it should, but the red close and green maximize
buttons are grayed out. (I haven't tried installing an extension yet.)
bug is still present in "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-DE;
rv:1.7.3) Gecko/20041026 Firefox/1.0" (1.0RC1)

re-requesting blocking-aviary1.0, as there are plans to release Mac 1.0
simultaniously with Win/Lin 1.0
Flags: blocking-aviary1.0- → blocking-aviary1.0?

Updated

13 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Comment on attachment 157169 [details] [diff] [review]
patch

r+a=ben@mozilla.org
Attachment #157169 - Flags: review?(bugs)
Attachment #157169 - Flags: review+
Attachment #157169 - Flags: approval-aviary+
chcked in. 
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Updated

13 years ago
Keywords: fixed-aviary1.0

Comment 22

13 years ago
*** Bug 250514 has been marked as a duplicate of this bug. ***

Updated

13 years ago
No longer blocks: 250514

Comment 23

13 years ago
*** Bug 268204 has been marked as a duplicate of this bug. ***
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.