28594 - Semi-freeze when cookie Confirm window gets hidden in the background

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect, P3)

Description

[Clement Cherlin]

From Bug Helper:
User-Agent: Mozilla/4.7 [en] (Win98; U)
BuildID:    2000021908
If the user has chosen to be prompted about attempts to set cookies, these query 
windows (titled Confirm) can be hidden. Some functionality is suspended until 
the Confirm window is dismissed, and if you hide a Confirm window without seeing 
it, which has happened to me several times, it seems exactly like the browser 
has frozen up.
Reproducible: Always
Steps to Reproduce:
1. In Preferences/Advanced/Cookies, enable cookies if disabled, and enable 'Warn 
me before accepting a cookie'.
2. Have at least two browser windows open. In one of them, visit any web page 
which sets cookies, that you do not have set to 'site can/cannot set cookies' in 
the Cookie Manager.
3. Cover the Confirm window with the other browser window, then attempt to click 
on links, type in text input areas, etc.
Actual Results:  The Confirm window is lost in the background, and is not 
trivially recovered. While the Confirm window is still open, Mozilla behaves as 
normal in some ways, but many things exhibit partially "frozen" behavior in 
unusual and inconsistent ways. I believe that this is because some parts of 
Mozilla are halted, waiting for the cookie Confirm window to be dismissed, while 
other threads continue normally. Some examples are listed below, and I can 
easily provide more if necessary.
Expected Results:  There are several ways in which Mozilla could handle this 
'correctly', in my opinion. 

Netscape 4.x handles this situation in a manner which is not entirely effective. 
It does correctly keep the cookie accept/reject window always on top of the 
window that spawned it, and it does bring them both to the foreground when the 
page attempts to set a cookie. The problem is that the browser window/cookie 
dialog pair together can still be lost in the background, and while you can use 
form widgets in other windows and click on links, many actions are queued up and 
not acted on until the cookie dialog is found (annoying when many browser 
windows are open) and dismissed.

In any case, a cookie confirmation window should always be on top of the window 
that spawns it. While a dialog is still open Mozilla should, in my opinion, do 
one of two things:

1. Keep the browser window that spawned the dialog always on top of all other 
Mozilla windows 
 OR
2. Allow other windows to function normally while the browser window/cookie 
dialog pair are in the background.

Number one seems to make sense for ease of implementation, but the second option 
allows the user to put off deciding whether to accept/reject cookies until they 
feel like it. Either one resolves the apparently-frozen problem.
Examples of curious behavior when a cookie dialog is pending:

(I do not currently use Mozilla for mail/news or page editing, so I will confine 
my comments to the Browser.)

Links on the toolbar DO work.
Typing in URLs in the URL field DOES work.
Links on pages DO NOT work. (This may not be universally true, I seem to have 
gotten this to work while a confirmation window was still open, but I may have 
accidentally had two different builds open.)

Normal pull-down menus work SOMETIMES. Right now I have one window open to 
www.sluggy.com (an ad banner on this site attempted to issue a cookie for 
.flycast.com) and the other window open to www.blizzard.com. In the blizzard.com 
window, the Go, Bookmarks and Tasks menus will pull down correctly; the others 
simply highlight the menu name when the mouse is over them, but the menu does 
not appear. However, in the sluggy.com window, all menus pull down correctly. 
Side-menus labled with triangles (bookmark sub-folders, Tasks/Tools, etc.) do 
NOT appear in either window when the mouse is held over their entry in the menu 
OR when the mouse is clicked on it. The menu simply closes when a side-menu 
entry is clicked on.

Scrolling with the mouse DOES work with build 2000021908, this did NOT work in 
M13. Keyboard-arrow scrolling works in both builds.

I'll try out any further tests upon request.

Comment 1

[Stephen P. Morse]

This is a dialog issue having nothing to do with cookies.  The same behavior 
would undoubtedly be observed if the page put up any other dialog such as http 
authentication.  Also will probably occur if the user brings up a dialog such as 
open-new-webpage.

Reassigning to danm.

Comment 2

[sarnold]

This is most likely a dup of bug 27117. (Which was reported under linux, so
window manager is out of the question -- this is Win98! :)

Comment 3

[Clement Cherlin]

I've tested this with several builds in the past week, and this bug does occur 
with cookie confirmation and http-authentication dialogs but not 
open-web-location.

Comment 4

[Clement Cherlin]

Sorry. I've tested this *on Win98 only* with several builds in the past week.

Comment 5

[Sean Richardson]

Confirmed with the 2000-03-01-08-M15 nightly binary on WinNT 4.0.

This is looking like a case that got missed in the existing partial fix for
bug 19221, "Dialog Modality added for Bug 10000 causes bad UE bustage", M15.

Note that the Confirm Cookie dialog can end up behind its parent window.

Links activated in the "other" window queue up... after the Confirm Cookie
dialog is cleared, only the last is loaded, but any and all links clicked
in the meantime end up in the Session History. I'll file a new bug for this.

Comment 6

[Dan M]

sidr is right about the roots of this problem, which lie in the dirt where many 
modal windows (cookies, for example) don't have a parent window, and so on 
platforms like Windows can't really behave modally. We're working toward a 
solution.

Comment 7

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 8

[Peter Trudelle]

nominating for nsbeta2

Comment 9

[Peter Trudelle]

[nsbeta2+] will take fix by 6/1

Comment 10

[Peter Trudelle]

Mass moving all dated nsbeta2+ bugs to M19

Comment 11

[Sean Richardson]

This problem is slightly better now...

Earlier, it was possible for the "Confirm Cookie" dialog to end up behind
another Mozilla window. Now, it ends up in front of all browser windows at
all times, so from a UI perspective it is much less likely to be the cause
of an apparent freeze. Given that, this may be relnote-able -- but see also
bug 39439, "modal dialogs become inaccessible", nsbeta2+ (undated).

OTOH, the "Confirm Cookie" dialog is still modal w.r.t. *all* browser windows.

Tested with the 2000-06-05-08-M16 nightly binary on WinNT.

Comment 12

[leger]

Updating from [6/1] to [6/15]

Comment 13

[Jim Roskind]

Cleaning up the status whiteboard by marking beta2 minus (6/15 has passed)

Based on Danm's comment, it sure sounds like this bug is fixed... as the dialog 
will be in front of *all* Navigator windows.  Since danm suggested a relnote is 
still called for, I'll add that keyword as well.

Dan: Can you be specific about what the release note should say?

Thanks,

Jim

Comment 14

[Dan M]

moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone

Comment 15

[Gervase Markham [:gerv]]

This is one of a maze of bugs - is this problem still there? Hence:

It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note for Netscape 6 RTM. If anyone feels it does, can they please 
draft one and then nominate with the relnote-user or relnote-devel strings in 
the Status Whiteboard.

Thanks :-)

Gerv

Comment 16

[Paul Chen]

nav triage team:

We would like modality issues solved in 6.5 time frame. But we don't know 
xptoolkit schedule or availability. Nominating for nsbeta1. Would like xptoolkit 
folks to comment whether or not they will get to this for 6.5.

Comment 17

[Paul Chen]

Whoops, that's more like next release of NS 6 whatever marketing decides to call 
it. ;-)

Comment 18

[Dan M]

The modality problem described here has generally been solved. There are still a 
couple of issues: (1) occasionally a modal dialog is still spun up using the 
nefarious Hidden Window for its parent, and (2) on Linux, modal windows lock out 
user interaction with all other windows while insisting on remaining in front of 
only their one parent window.

Problem 1 is nearly fixed; there are still rare (?) instances that need to be 
shaken out as a piece of the work for making Gecko embeddable. That's covered 
elsewhere, like bug 44809. Problem 2 is a condition of gtk, and it's something 
I'm not personally signed up to fix. We're stuck with that until we remove gtk, 
which is something we think about every now and then. (It's also covered by bug 
19221, or what that bug morphed into: see comments in it, dated 11-08-2000).

This bug really isn't a duplicate of those two others, but it will be fixed on 
the shiny day when those two others are fixed. Marking dependent on them, and 
leaving futured.

Comment 19

[Thomas]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714

I tried to replicate the problem, but it doesn't slow me down.
Can anyone confirm this bug is fixed?

Comment 20

[benc]

RESOLVED/FIXED, per danm's comments and the fixed depends.

I've used cookies for sometime, and the warning behavior seems pretty rational
to me.