preferences dialog from modal browser locks up app

VERIFIED WORKSFORME

Status

P3
major
VERIFIED WORKSFORME
18 years ago
14 years ago

People

(Reporter: bugzilla, Assigned: paulkchen)

Tracking

({hang, platform-parity})

Trunk
mozilla1.0
x86
Windows ME
hang, platform-parity

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
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

18 years ago
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.

(Reporter)

Comment 2

18 years ago
> 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

18 years ago
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

18 years ago
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

Comment 5

18 years ago
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
(Reporter)

Comment 6

18 years ago
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?

Updated

18 years ago
Keywords: freeze
(Reporter)

Comment 7

18 years ago
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.
Keywords: freeze

Comment 8

18 years ago
  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. ***

Comment 10

18 years ago
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
Component: XP Apps → Preferences
(Assignee)

Comment 11

18 years ago
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

Comment 13

18 years ago
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.

Updated

18 years ago
Blocks: 77007

Updated

18 years ago
No longer blocks: 77007

Comment 14

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

Updated

18 years ago
Keywords: nsCatFood → nsCatFood+
Target Milestone: Future → mozilla0.9.1
(Assignee)

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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. ***
(Assignee)

Comment 17

17 years ago
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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.