314072 - all ui elements disabled if "set camino as default" popup releases focus to under the browser window

Status: RESOLVED FIXED

(Camino Graveyard :: OS Integration, defect, P2)

Description

[Eric Garrido]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1

Upon first opening Camino, the "set camino as default" popup dialog appeared, but I didn't see it as I was distracted by another program, i then accidentally clicked on the camino window. several seconds later, i tried interacting with the browser, but no events were being handled, because the popup dialog disappeared beneath the browser window.

Reproducible: Always

Steps to Reproduce:
1. unset camino as the default browser
2. close, then open camino
3. click on browser window
Actual Results:  
popup dialog disappears, but browser is nonfunctional.

Expected Results:  
the popup dialog should maintain focus until it is answered; perhaps it should be cascade element, like the "save password" dialog.

Comment 1

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

I think Simon already fixed this when he fixed the "Warn when closing with multiple tabs" bit.  I'd check myself, but if I'm trying to test bug 307251, I can't :-(

Reporter, can you try this again with a current nightly build?

Comment 2

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

I looked at this in my testing account, and if I launch Camino, switch to another app, and then activate Camino by clicking on the browser window, the dialogue is still hidden.

Is this fixable for 1.0, or off to 1.1 with the rest of the locked/blocked state bugs?

Comment 3

[Simon Fraser [no longer active]]

Similar to bug 313025. What is it with our dialogs????

Comment 4

[Mike Pinkerton (not reading bugmail)]

is it because we're using depricated apis somewhere?

Comment 5

[Simon Fraser [no longer active]]

No, we're just using [NSApp runModalForWindow:] in the non-sheet case, which should work fine. NSRunAlertPanel must do more.

Comment 6

[deej]

Attachment: Image demonstrating UI conflict between proxy auth and the set default browser dialog.

Comment 7

[deej]

In Camino 1.0b1, I get a "stuck" situation on first run.

We use authenticated HTTP/HTTPS proxies. On first run, Camino tries to:
a) access the net, thus creating a request for proxy authentication
b) have the user make a decision about being the default proxy

The result is the screenshot you see attached. Neither dialog will clear. The closest I can get is to click OK or Cancel on the proxy dialog, however the buttons respond to my clicks but don't (appear to) do anything. I therefore have to force-quit.

Since I cannot clear the "Don't ask me again" for the "set default" dialog, the only way to workaround this has been to either disable the proxy settings in my System Preferences, or unplug my network (to prevent any proxy dialog from occuring). Once I've asked Camino to never ask me about the default browser again, I can set things back up the way they should, and get on with using Camino.

Comment 8

[Simon Fraser [no longer active]]

I think the "set as default browser" window should be non-modal. It should just be a regular window, as there is no reason for it to be blocking. That would at least solve this bug.

Comment 9

[Mike Pinkerton (not reading bugmail)]

did we recently change the behavior of the default browser window (like turn it off)? if so, is this bug still valid?

Comment 10

[Simon Fraser [no longer active]]

No, still an issue. We should disucss what we want to do with the default browser dialog.

Comment 11

[Mark Mentovai]

I wouldn't mind if the dialog wasn't modal.

Comment 12

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

In addition, when the default page finishes loading, it pulls focus away from the dialogue (the dialogue's still in front, but the browser window now has focus), which makes it even easier to accidentally make the dialogue totally disappear behind the browser window.

Comment 13

[Simon Fraser [no longer active]]

I think this should block RC1/1.0.

Comment 14

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

*** Bug 324559 has been marked as a duplicate of this bug. ***

Comment 15

[Simon Fraser [no longer active]]

Attachment: Patch

This patch fixes the symptom, but not the underlying cause.

The actual fix is to display a modal dialog, rather than a sheet, if there is already a modal dialog up. This prevents AppKit from locking up.

I also added code to throw exceptions if showing the sheet/dialog returns NSAlertErrorReturn, and subsequently catch those exceptions and return NS_ERROR_FAILURE (previously we'd just return NS_OK, which was bad).

Comment 16

[Simon Fraser [no longer active]]

The underlying cause that I alluded to is bug 301791. If we're in a -runModalForWindow loop, we probably shouldn't be processing PLEvents (which also means that we should be pushing nested event loop every time we call -runModalForWindow:).

Comment 17

[Mark Mentovai]

Comment on attachment 210002 [details] [diff] [review]
Patch

I don't love the rationale, but it really is the best we can do at the moment, and it's not such a common case.

+  // If there is already a modal window up, convert a sheet into a modal window,
+  // because AppKit will hang if you try to do this (possibly because we're using
+  // the deprecated and sucky runModalForWindow:relativeToWindow:).

Not disparaging enough.

Simon said he'd adjust the next line to also catch the case when the parent's already displaying a sheet, and turn the new sheet into a modal.

Other than that, r=me.

Comment 18

[Simon Fraser [no longer active]]

*** Bug 279350 has been marked as a duplicate of this bug. ***

Comment 19

[Simon Fraser [no longer active]]

Fixed.

Comment 20

[Ambrose Li]

This is NOT fixed (at least from a user's viewpoint).

I am seeing exactly this problem in the new Camino 2006042704 (v1.01int) build that I just installed. (I have never used Camino before.) The funny thing is, I couldn't figure out what happened, and when I tried everything I could think of (including trying to send a Quit command from the Dock), I brought up the Force Quit window, and then the modal dialog appeared for no reason.

So it either is "fixed" only in CVS but not in the new build (in which case we need a new build for ppl to download), or it has not really been fixed, or this is a regression.

Comment 21

[Ambrose Li]

After rereading the previous comments, I am reporting that my situation is slightly different.

When I first ran Camino, I clicked a window of some other app and continued to work in that app. Then Camino's windows appeared and its icon began flashing in the Dock. When I click the icon in the dock, I see a normally-looking browser window (NOTE: there is no modal dialog on the screen, just the browser window), but no matter what I do, I just get a beep. If I pull down menus, almost everything is disabled; some commands (e.g., File|Close) are not disabled, but selecting them just results in a beep. If I right-click Camino's icon in the Dock, I can choose the Quit command (normal Quit command, not Force Quit) but it does nothing.

The only way to get out of the above situation is to bring up the Force Quit dialog, which for no obvious reason makes the "do you want camino to be the default browser?" dialog appear. And then I can dismiss the window normally.

In other words, in some circumstances, Camino's first modal dialog can block Camino without appearing on the screen at all, resulting in the situation that the user sees an unresponsive Camino but will have no way of knowing that it is unresponsive because an invisible modal dialog is waiting for responses.

Comment 22

[Chris Lawson (gone)]

Ambrose: see bug 287784 for more similar bugs (as well as the dependencies/blockers here). What you're describing sounds like something we've seen before, but we have several mildly different versions of this problem.

cl