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.
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.
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 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-
it is bug 194323. But they didn't accept that patch either.
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
This was fixed via bug 212459 and bug 251991.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.