62903 - preferences dialog from modal browser locks up app

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect, P3)

Description

[Blake Ross]

Build ID: 12/14 trunk

Steps to Reproduce:

(1) Start one instance of Mozilla.
(2) Open the prefs dialog (Edit | Preferences...).
(3) Go to Navigator > Smart Browsing.
(4) Click the `More Information...' button.
(5) In the new modal window that appears, open the prefs dialog.

Actual Result: Focus is set to the prefs dialog that's modal to the old (non-
modal) instance of navigator.  But you can't, of course, access it, since you 
have the new modal window in front.

Expected Result: Ideally, the user should be allowed to open a new preferences 
dialog from the new modal window.  The average person doesn't know or care 
about modality, he just wants his preferences dialog to open.

Comment 1

[John Morrison]

Great googly-moogly, that's a mess, although I think the bigger flaw is 
bringing up a full-featured Navigator window as a modal child in the first 
place.

> Ideally, the user should be allowed to open a new preferences dialog from 
> the new modal window.

I don't agree. That would mean you would have two prefwindow sessions running
concurrently; which set of changes is committed? (Or to put it another way, 
users would be more confused by having two identical modal dialogs up at the 
same time, particularly when their changes are not committed.).

There is, though, another example where you can get a third, distinct, modal 
child dialog up -- do 'View->Character Coding->Customize...' from the second 
Navigator window. 

But again, we really should not ever bring up a full-featured Navigator window
as a modal dialog.

Comment 2

[Blake Ross]

> Although I think the bigger flaw is bringing up a full-featured Navigator 
> window as a modal child in the first place.

I agree completely; I was going to find and reopen that bug before but forgot.

> That would mean you would have two prefwindow sessions running
> concurrently; which set of changes is committed?

Hmm..that's a good point.  I thought we did this anyways when the user opened 
two windows and the preferences dialog in each, but apparently not.  

So I think we should fix that modal browser instance, but aside from that, is 
there a deeper window layering bug here?

Comment 3

[John Morrison]

Yes. If there is a bug on this particular "Navigator-as-a-modal-window" thing,
then that should be opened/reopened/something. 

There may be a defect here, although a defect related to getting a 
great-grandchild modal dialog is a tad outside normal operating boundaries.

Comment 4

[Dan M]

I second that great googly-moogly. But probably for a different reason. The 
second browser window is intentionally modal; see bug 58829. We're running out of 
possible solutions for the web of side effects. I'm thinking of solutions like 
disabling the "prefs" menu item in the modal browser window. Or getting rid of 
the damn fool button in the modal dialog that opens a whole new browser.

Comment 5

[Dan M]

I'm changing the summary to reflect the actual case. It isn't as general as the 
previous summary implied. The bug is restricted to the specific case where a 
modal browser window, asked to open the preferences dialog, detects one already 
open and foolishly activates it. This pretty much only happens if you exactly 
follow Blake's steps above. Similar situations just open a new modal dialog.

Comment 6

[Blake Ross]

Yeah, I know why it (58829) was done.  I'm thinking we should just bring up a 
little info window with a close button, like we do in other places.  This was 
discussed early in the bug.  So Dan, is there more you'll need to do here?

Comment 7

[Blake Ross]

This doesn't lock up the app...

I don't even think Dan needs to do anything here; we just shouldn't bring up a 
modal navigator window.

Comment 8

[Dan M]

  That would be a fine solution, bringing up a less dramatic info window. Easier 
said than done, though, since it's all configurable, and the Netscape builds 
point that button to pages on their servers, with the idea that they can update 
that info at any time. Got a plan?
  Other possibilities I think haven't been mentioned yet would be to make the 
preferences window nonmodal, or to navigate the parent browser window to the Info 
URL, rather than opening a new one. The first case isn't so bad because a modal 
preferences window is kind of pointless, anyway, since you can't protect yourself 
from live browser windows on any platform but the Mac. The second case isn't so 
bad because of the "back" button.
  And there's your suggestion of no stinking browser windows. Any of these (and 
others) are fine solutions by me, though there is the troubling loss of 
configurability with the one.

Comment 9

[sairuh (rarely reading bugmail)]

*** Bug 61350 has been marked as a duplicate of this bug. ***

Comment 10

[Peter Trudelle]

I agree with Blake, this is just not supported. ->xpapps.

Comment 11

[Paul Chen]

Marking future, why was this marked mozilla0.9?

Comment 12

[sairuh (rarely reading bugmail)]

still hangs [using 2001.04.20.14 bits on winNT]. seems only applicable to win32?
[couldn't repro the problem on linux or mac.]

Comment 13

[Matthew T (active 1999-2002)]

This is a deeper window layering problem, it's not just a browser problem. I've 
been trying to see what menus the Certificate Manager has; but I can't, because 
the Certificate Manager is opened from the Preferences, and while the menus 
look enabled, I can't open any of them. Nor can I close the prefs dialog while 
keeping the Certificate Manager open, which I should be able to.

Making the browser window modal is a very poor solution to the problem. Only 
dialogs should be modal, windows never should be. It doesn't make any sense 
that I can't switch to other browser windows, or that I can't select any of the 
menu items. What if the text in the `More Information' window is in the wrong 
encoding, and I need to change it in the `View' menu? I can't open the `View' 
menu, so I'm stuck.

You could fix this particular manifestation by making the Preferences window
non-modal, but that wouldn't fix the whole problem. Other dialogs and alerts 
which *need* to be modal are eventually going to be opening the help viewer all 
over the place, and requiring that the user close the help viewer before 
following its instructions in the modal dialog would just about defeat the 
purpose of having online help at all.

Comment 14

[Matthew T (active 1999-2002)]

*** Bug 77007 has been marked as a duplicate of this bug. ***

Comment 15

[Viswanath Ramachandran]

nav triage: not critical to rtm, moving to m1.0. 

Comment 16

[sairuh (rarely reading bugmail)]

*** Bug 87089 has been marked as a duplicate of this bug. ***

Comment 17

[Paul Chen]

Using my mac build from this morning, the prefs window isn't modal anymore, so
I'll mark this w4m.

Comment 18

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)