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

Status: VERIFIED DUPLICATE of bug 65521

(SeaMonkey :: Preferences, defect)

Description

[vectro]

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.

Comment 1

[Fabian Guisset]

what does "Go back to original window" on step 2 mean? It's impossible since
pref is a modal dialog.

Comment 2

[vectro]

Sorry, I meant the window used to create the preferences dialog.

Comment 3

[timeless]

preferences is modal. we don't intend to fix this any time soon. there are bugs 
for that.

Comment 4

[vectro]

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?

Comment 5

[timeless]

because we suck, but that's a different bug.

Comment 6

[Matthew T (active 1999-2002)]

Timeless, behave yourself. If this is a duplicate, mark it as such. Otherwise, 
it's a valid bug.

Comment 7

[sairuh (rarely reading bugmail)]

i believe this is expected behavior... cc'ing danm and morse for confirmation
[or, denial ;)].

Comment 8

[Stephen P. Morse]

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).

Comment 9

[Stephen P. Morse]

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.

Comment 10

[Dan M]

  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 ***

Comment 11

[vectro]

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.

Comment 12

[Dan M]

  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.

Comment 13

[vectro]

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.

Comment 14

[Dan M]

  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.

Comment 15

[sairuh (rarely reading bugmail)]

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.