certManager, deviceManager and crlManager should be dialog instead of window

RESOLVED FIXED

Status

Core Graveyard
Security: UI
RESOLVED FIXED
15 years ago
a year ago

People

(Reporter: Robin Lu, Unassigned)

Tracking

Other Branch
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
Firstly, it is inconsistence with the other managers like cookie manager which
cause bug 181652.
More serious, if you use metacity, which has a feature to Keep dialogs without
transient parent above entire app (
http://bugzilla.gnome.org/show_bug.cgi?id=88926 ), following bug happens
according to http://bugzilla.gnome.org/show_bug.cgi?id=104789 :

Package: metacity
Product: metacity
Synopsis: Metacity handles window focus in Netscape Incorrectly
Severity: normal
Priority: High
Bugzilla-Product: metacity
BugBuddy-GnomeVersion: 2.0

With Netscape 7 and GNOME 2.0 it is impossible to get the certificate manager
window in front of the "preferences" window.  This makes reading and working
with the certificate manager window very difficult.

To duplicate, start netscape 7, open "edit-preferences", drop down the menu item
"Privacy & Security", then select "Certificates".  Then click either "Manage
Certificates" or "manage security devices", the dialog boxes will appear behind
the "preferences" window.

On Small low res displays like SunRay LCDs this could be a major problem.
(Reporter)

Comment 1

15 years ago
Created attachment 114973 [details] [diff] [review]
patch
(Reporter)

Updated

15 years ago
Attachment #114973 - Flags: review?(kaie)

Comment 2

15 years ago
So the problem is, we show a dialog, and from within the dialog, we open a
window - and on your particular windowing system, windows are always shown
behind dialogs.


I understand the problem, but I think we should not change the types of cert
manager etc. to dialogs. By using a dialog, which has an OK button, we would
give the user the impression that no action will be effective until the user
presses the OK button. That's not true. Cert Manager is a complex window where
all actions take effect immediately.

Cert Manager also needs a lot of space because of its multiple columns. That
makes it a primary candidate for allowing the user to enlarge the window. I
tried your patch, and a drawback of the patch is, that certificate manager no
longer remembers the manual adjusted size the user gives to the window: Open
Cert manager, enlarge, close, open again, cert manager no longer has the
previous size.


I wish we would be able to find another solution for the special behaviour of
that windowing system.


Of course, the simplest workaround is: Have the user close the preferences
dialog after the other manager was opened. But I understand that is confusing
and users might believe that nothing happened when they clicked the button.


In my opinion, this behaviour shows us that we have a user interface design
problem here. The user is within a preferences dialog, but those manager windows
do not run within the context of the prefs dialog. Instead, they are separate
windows.


I think, the ideal solution would be:
- no longer allow the cert manager, etc. windows to be opened from within the
preferences dialog. Only use the preferences dialog for simple settings.

- move the command to open those windows to a different place in the UI. I can
imagine two places, the Tools menu, where we could have a security submenu,
which itself has three submenus for the security managers - and possibly in
addition to the view page info window, where we could have buttons to allow
opening the manager windows.


However, since users are already used to find those windows in prefs, and
opening the windows from there does not cause a problem on most windowing
systems, I propose we leave the ability to access them from there, and provide
the window access in the tools menu in addition.

That means, by having the ability to the window managers in addition, we could
recommend the users on your platform to use the tools menu instead.

I understand this is not the best solution for your platform, but maybe it is an
acceptable compromise?


One more idea, is the windowing behaviour known at compile time on your
operating system? Maybe you could use a patch that disables accesing the windows
from the prefs dialog on that system.
(Reporter)

Comment 3

15 years ago
But don't the cookie manager, image permissions manager, form manager and etc
all acts before the 'close button' being clicked? Also, some of these manager
windows have multi columns.

Another reason of this bug is that the preference dialog does not set transient
parent to any of the window in linux and solaris. If it set the transient
parent, it would only in front of its transient parent and won't block any other
window. I will file a bug for that. But I still think those manage windows
should be dialog and have consistence style with others.

Comment 4

15 years ago
Comment on attachment 114973 [details] [diff] [review]
patch

Robin, is this patch still valid?

I remember a discussion in another bug were you discussed to solve this in a
completely different way.

I still would prefer not to change the way the windows are currently behaving.
Attachment #114973 - Flags: review?(kaie) → review-
(Reporter)

Comment 5

15 years ago
it is bug 194323. But they didn't accept that patch either.

Comment 6

14 years ago
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody

Comment 7

13 years ago
This was fixed via bug 212459 and bug 251991.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Updated

13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core
(Assignee)

Updated

a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.