354643 - "Default browser" dialogue at first launch can still become hidden and disable all Camino UI

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: General, defect)

Description

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

Since bug 314072 was fixed, we've gotten sporadic reports of it continuing to happen, and once in a while I've seen it myself with fresh profile testing, but I've never found reliable steps to cause it.  Until now.

STR:
1) Launch Camino with a fresh profile
2) Switch away from Camino as soon as it begins launching/takes focus
3) *Wait* until the initial page has *finished* loading completely (helps if you can see the progress bar)
4) *Click* back to Camino, either via the Dock icon (bouncing) or simply finding part of the content/chrome

Ta-da! (At this point, clicking into another app will show the dialog; it's "inactive" but still blocking; a second click activates it and lets you choose an option and go on with your Camino-ing).

3 and 4 are the key ingredients; I can also reproduce sometimes by switching back before the page is completely loaded (a "sufficiently long" bit of time), but it's more of a race then as to whether it happens.

This seems to be partially related to us focusing the content area (and thus the browser window, apparently) when a page finishes loading; you can see this just by watching this startup process with Camino as the active/frontmost app.  It may also be partially related to nested event queue evilness, or whatever. 

The fact that clicking on the bouncing Dock icon doesn't do the right thing (only cmd-tab does) is bothersome...it would be nice to fix this for that reason, but I'm not hung up on it making 1.1.  Long term, smfr and mento seem to want to make this a non-modal regular window instead of a dialog (see bug 314072 comment 8).

Comment 1

[Denis]

Bit by this on first launch of the browser. Not the kind of experience that would make me chose Camino as my default browser ;}

Comment 2

[Mark Mentovai]

First impressions are important, maybe we can move this up?

Comment 3

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

If we get a patch for this before 1.1, I'm all for it, but compared to the other remaining 1.1 bugs, it's not a blocker.

Comment 4

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

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Comment 5

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

I *think* this is caused by our call to focus the page when the page is done loading. If I sit and watch a default startup, the dialogue is focused until the page finishes loading, at which point the page gets focused and the dialogue becomes unfocused (though still in front).  When the app is not the active one, this somehow leads to the dialogue becoming hidden behind the newly-focused page.

Stuart has talked about making this a non-modal thing, or even moving the check to first quit (though any "open in default browser" events during the first session will go to another browser, which seems bad), so we may just want to fix this bug by ripping out the current impl unless anyone comes up with a fix quickly.