279350 - Interface lock when File>Open dialogue present and site opened by webloc drag to Dock asks for cookie

Status: VERIFIED DUPLICATE of bug 314072

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is yet another variation on the general "interface lock"/trapped UI element
theme (see bug 187849, bug 189298, bug 163830, bug 187047, bug 157715, bug
181721, bug 274979), but a little more convoluted/complex.

If I'm being forgetful while testing :-) and do File>Open, then go drag a webloc
to the Dock icon (without closing the Open File dialogue) and the resulting site
asks to set a cookie ("Ask before accepting each cookie" checked in the prefs),
I'm stuck with an interface lock and must force quit.  

The cookie sheet is "active"--but hidden behind the frontmost and inactive Open
File dialogue--but won't respond to key commands (Esc or Enter) and the Open
File dialogue can't be made active, either.  Menus are clickable but most of the
items greyed out (including Quit) and Cmd-Q doesn't work, either, because the
Open File dialogue was previously "active".  The only way out is force quit.

The site in the URL will give you a cookie (unless you have one from them
already, I presume.)

2005012108 (v0.8+) Mac OS X 10.3.7

Comment 1

[Bill Kocik]

The behavior of this appears to have changed. The interface no longer freezes. Instead, what happens is while the file dialogue is open, any cookie prompts that pop up are automatically responded to somehow.

If I set my prefs to allow cookies but ask before setting, then open an "Open File" dialogue, then drag a webloc to the Camino icon in the dock and that webloc opens a page that sets cookies, I hear a system beep for each cookie prompt. But the cookie prompts never display. Instead, the page loads, and when I cancel out of the open file dialogue and go look at my settings, I now have an exception added for each of the domains a cookie was set from. Also, I don't see the cookies that were set in the cookie list.

This is very strange. Can anyone confirm this behavior?

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

 > This is very strange. Can anyone confirm this behavior?

I can confirm the new behavior with 2005110404 (v1.0a1+).  No cookies get set because the "magic answering of the dialogue" has chosen to add the site to the Exceptions list as "Deny", at least in my case.

When did we start using sheets for the File:Open dialogue?  Is that what changed this?  Or did one of the prompt fixes from this summer do something?

At any rate, removing hang, lowering severity, and pushing off to 1.1 with the rest of its kin.

Comment 3

[Mike Pinkerton (not reading bugmail)]

i thought simon made these dialogs sheets. can we change the default somehow, or is this hard-coded OS behavior to prevent deadlock?

Comment 4

[Simon Fraser [no longer active]]

(In reply to comment #1)

> Instead, what happens is while the file dialogue is open, any cookie prompts
> that pop up are automatically responded to somehow.

What's happening is that [NSApp runModalForWindow...] is returning NSAlertErrorReturn, which we just ignore. This is bad.

Comment 5

[Simon Fraser [no longer active]]

I think we also have an interface lock when the "Do you want to set camino as your default browser" dialog is up, and you get a Cookie prompt sheet. We had a user get this on their first run of 1.0b1: not good.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Bug 314072 comment 7?

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I think we minus this one and only worry about the new, first-launch locking issue (bug 314072) for 1.0; we need to ship.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Moving off per irc.

Comment 9

[Simon Fraser [no longer active]]

Will be fixed by the patch in bug 314072.

*** This bug has been marked as a duplicate of 314072 ***