Closed Bug 65522 Opened 21 years ago Closed 21 years ago

Opening a new window with cookies dialog open, one cannot interact with new window until preferences is closed.

Categories

(SeaMonkey :: Preferences, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 65521

People

(Reporter: vectro, Assigned: matt)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; 0.7) Gecko/20010105
BuildID:    2001010517

Preferences...Advanced...Cookies...View Stored Cookies dialog seems to block
interaction with new windows.

Reproducible: Always
Steps to Reproduce:
1) Go to Edit...Preferences...Advanced...Cookies...View Stored Cookies
2) Go back to original window, and hit CTRL-N
3) New window appears, but can't interact with any of the widgets until
preferences is closed.
what does "Go back to original window" on step 2 mean? It's impossible since
pref is a modal dialog.
Sorry, I meant the window used to create the preferences dialog.
preferences is modal. we don't intend to fix this any time soon. there are bugs 
for that.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
I don't think we're communicating correctly here.

When I say "Go back to the main window", I'm not talking about the main
preferences window -- I'm talking about the main browser window used to create
the preferences window. E.g. the window where the user goes to edit...preferences.

If you're not supposed to be able to use the main browser window when the
preferences dialog is open, then why are you allowed to open a new browser
window.in the first place?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
because we suck, but that's a different bug.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → INVALID
Timeless, behave yourself. If this is a duplicate, mark it as such. Otherwise, 
it's a valid bug.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
i believe this is expected behavior... cc'ing danm and morse for confirmation
[or, denial ;)].
I'm very confused here.  How can you go back to the "original window" or the 
"window used to create the preferences dialog" or the "main browser window used 
to createthe preferences window" (or any other variation on the wording) since 
both the cookie-manager window and the pref window are modal.  When you are in 
the cooke-manager window, you can't get back to any other window.  Likewise if 
you are in the pref window (before opening the cookie-manager window).
Furthermore, you asked:

   If you're not supposed to be able to use the main browser window when the
   preferences dialog is open, then why are you allowed to open a new browser
   window.in the first place?

Please clarify this.  What do you mean by "allowed to open a new browser 
window"?  Give more explicit details as to exactly what you are doing.
  Remember we're talking Linux here. The prefs window isn't modal in the Linux 
build. The original browser window will be unresponsive while the modal "View 
Cookies" dialog is up; that's bug 19221 or the more recently minted, more 
accurately descriptive bug 65521. Any other new window you manage to bring up 
despite gtk modality's best intentions will be similarly unresponsive.
  Oddly though, I can't do step (2) in the steps to reproduce. That's odd, 
because that's a known bug 53476 (see especially its duplicate, bug 62544). 
Hmmph. Perhaps someone fixed that one.
  Anyway, take your pick. This bug's a duplicate of one of those.


*** This bug has been marked as a duplicate of 65521 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → DUPLICATE
OK. When the user chooses Edit..Preferences from a browser window, it brings up 
a new preferences window, which is modal; That is, subwindows of the preferences 
window (e.g. view stored cookies window) do not show up on taskbars and block 
interaction with the preferences window. Interaction with other Mozilla windows, 
such as the browser window where edit...preferences was selected, or any other 
mozilla windows should not be blocked.

With that in mind, here is a description of what I am doing:
1) Mozilla has just been started. There is only 1 window -- a browser window. 
This step is not necessary, but makes things clearer.
2) In the aforementioned browser window, user chooses "Preferences" from the 
"Edit" menu.
3) This creates a new, modal, preferences window, which is seperate from the 
browser window used to bring it up.
4) In aforementioned Preferences window, user chosses Advanced, then Cookies, 
then clicks on the "View stored cookies" button.
5) This creates a new window for managing cookies, which is part of the modal 
preferences window.
6) User returns to the browser window mentioned in step 1.
7) User selects "New Navigator window" from the "File" menu of this browser 
window.
8) This creates a new browser window, sepereate from the browser window created 
in step 1 or the preferences window created in step 3.
9) User cannot interact with the new browser window (created in step 8), until 
the cookies sub-window (created in step 5) is closed.
  OK, to be precise, the preferences window isn't necessarily nonmodal on unix. 
It's controlled by a preference which by default makes it nonmodal on unix, modal 
everywhere else. The condition you describe ("subwindows of the preferences 
window ... block interaction with the preferences window") suggests the subwindow 
(View Stored Cookies) is modal, but says nothing about the preferences 
themselves.
  Still, modal windows are application modal in our Linux build (bug 65521), and 
once you have a modal window up (step 4) all other windows should go 
unresponsive. How you manage to accomplish step 7 under these circumstances is a 
mystery. I can't do it on my Redhat/Enlightenment build. However, bug 53476 was 
once a way to get past the modal lockout and conceivably open a new window. I had 
imagined that was how you were doing this, though that doesn't seem to be what 
you're saying. Regardless, *all* windows other than the modal Cookies window, 
including a browser window newly opened by whatever means, should be unresponsive 
(bug 65521 again), so that part's no mystery.
  The curious thing is, how did you manage to do step 7 without the bug 53476 
keyboard shortcut sidestep? Ignoring that, which is not what this bug was written 
up about though it could be related; the bug you were discussing, that the new 
browser is unresponsive, is a side effect of the too-global modal UI lockout. And 
that's a known bug.
Dunno. I'm running KDE2. The preferences window shows up on my taskbar as a
seperate window, although the cookies window does not. I just clicked on the
taskbar (or move the preferences window out of the way and click on the main
browser window, or hit ctrl-tab, etc.) and the main window remains perfectly
responsive. In fact I'm typing this right now, with the preferences window open.
  Hmm. On my machine, all three windows (browser, preferences, cookieviewer) show 
up in the taskbar. And all windows (browser, prefences, mail, whatever) go 
unresponsive when you open the cookieviewer. That's the somewhat broken behaviour 
we're expecting.
  It's odd that you still have a live first window. If you open two browsers 
before opening preferences, are both browsers (and prefs) still responsive after 
you open cookieviewer? That's weird. In the best world, the prefs window and the 
browser that spawned it should go dead, while the second browser (and any windows 
you opened from it) would remain live. In our current world, all windows but 
cookieviewer (should) go dead.
  Still, the new window lockout you're seeing is part of the standard (somewhat 
broken) application global characteristic of modal windows, and one imagines that 
this specific problem would fall to the general fix for that one.
mass verification of duplicate bugs: to find all bugspam pertaining to this, set
your search string to "DuplicateBugsBelongInZahadum".

if you think this particular bug is *not* a duplicate, please provide a
compelling reason, as well as check a recent *trunk* build (on the appropriate
platform[s]), before reopening.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.