If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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



Camino Graveyard
OS Integration
12 years ago
12 years ago


(Reporter: Eric Garrido, Assigned: Simon Fraser)


(Depends on: 1 bug, {fixed1.8.0.1, fixed1.8.1})

Mac OS X
fixed1.8.0.1, fixed1.8.1
Dependency tree / graph
Bug Flags:
camino1.0 +



(2 attachments)



12 years ago
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.
Blocks: 294129
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?
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?
Ever confirmed: true

Comment 3

12 years ago
Similar to bug 313025. What is it with our dialogs????
Flags: camino1.0+
Target Milestone: --- → Camino1.0
is it because we're using depricated apis somewhere?

Comment 5

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

Comment 6

12 years ago
Created attachment 202180 [details]
Image demonstrating UI conflict between proxy auth and the set default browser dialog.

Comment 7

12 years ago
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.


12 years ago
Severity: minor → major
Priority: -- → P2

Comment 8

12 years ago
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.
did we recently change the behavior of the default browser window (like turn it off)? if so, is this bug still valid?

Comment 10

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

Comment 11

12 years ago
I wouldn't mind if the dialog wasn't modal.
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

12 years ago
I think this should block RC1/1.0.
*** Bug 324559 has been marked as a duplicate of this bug. ***


12 years ago
Assignee: mikepinkerton → sfraser_bugs


12 years ago
Depends on: 301791

Comment 15

12 years ago
Created attachment 210002 [details] [diff] [review]

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

12 years ago
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

12 years ago
Comment on attachment 210002 [details] [diff] [review]

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.
Attachment #210002 - Flags: review+

Comment 18

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

Comment 19

12 years ago
Last Resolved: 12 years ago
Keywords: fixed1.8.0.1, fixed1.8.1
Resolution: --- → FIXED

Comment 20

12 years ago
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

12 years ago
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

12 years ago
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.

You need to log in before you can comment on or make changes to this bug.