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.
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.
> 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?
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.
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
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.
Summary: Can't bring up new modal dialog from modal child → preferences dialog from modal browser locks up app
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?
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.
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.
*** Bug 61350 has been marked as a duplicate of this bug. ***
I agree with Blake, this is just not supported. ->xpapps.
Assignee: danm → pchen
Status: ASSIGNED → NEW
Component: XP Toolkit/Widgets → XP Apps
QA Contact: jrgm → sairuh
Marking future, why was this marked mozilla0.9?
Target Milestone: mozilla0.9 → Future
still hangs [using 2001.04.20.14 bits on winNT]. seems only applicable to win32? [couldn't repro the problem on linux or mac.]
Severity: normal → major
Keywords: hang, nsCatFood, pp
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.
*** Bug 77007 has been marked as a duplicate of this bug. ***
Keywords: nsCatFood → nsCatFood+
Target Milestone: Future → mozilla0.9.1
nav triage: not critical to rtm, moving to m1.0.
Target Milestone: mozilla0.9.2 → mozilla1.0
*** Bug 87089 has been marked as a duplicate of this bug. ***
Using my mac build from this morning, the prefs window isn't modal anymore, so I'll mark this w4m.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
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 :)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.