289020 - Default browser setting won't set new Camino as default if old version has been moved to Trash

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Preferences, defect)

Description

[Stefan Winopal]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050402 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050402 Camino/0.8+

Camino's default browser preference doesn't allow Camino to be set as default
browser after upgrading

Reproducible: Didn't try

Steps to Reproduce:
I haven't tried to reproduce this because I don't know how to get it working
again. So here's what I've done.

1. Had an older 0.8+ (0.9) build, renamed it to "Camino 0.9"
2. Installed 0.8.3 as "Camino", toyed around with it.
3. Deleted both, placed new recent 0.8+ in Applications as "Camino"

Actual Results:  
Camino assumes now, every time when I try to use it to set it as default, that
it's executable has been deleted. Obviously this is untrue. Setting Camino as
default with Safari works.

Expected Results:  
Camino recognizes that it has been re-installed and updates the link in the
default browser setting correctly, so it's able to set itself as system's
default again.

Comment 1

[Samuel Sidler (old account; do not CC)]

Is this bug related to the fix for bug 287380? Josh, I'm CCing you to look at this.

Comment 2

[Josh Aas]

I'm not sure I understand... what is the UI implication of what you are saying?
Is Camino not showing up in the menu at all? You are incapable of selecting it?
It is incorrectly selected?

You cannot tell Launch Services to set a particular instance of an application
as the default. It only takes a bundle ID and then picks whatever instance it
wants. That doesn't sound like what you're having trouble with, but just in case...

Comment 3

[Stefan Winopal]

No the menu shows up correctly. The UI looks nice, and I'm able to set Safari,
Firefox, whatever I want (even NetNewsWire) as default. But as soon as I select
Camino it displays a window saying: "The default browser you have chosen no
longer exists. Please choose another browser."

This is of cause wrong, because Camino.app exists. Perhaps something is wrong
with the implementation of how Camino gets items for this list? Probaply because
I renamed the older 0.9 before deleting it? Does Camino store the name of the
bundle somewhere?

Perhaps following information is helpful as well: While writing this only one
copy of any version of Camino is present on my Mac. (See User-Agent for
details.) This one copy still encounters problems setting itself as default
browser. Since I had this problem the first time I updated to later nightlies
one or two times.

Comment 4

[Josh Aas]

Ahh - I get it. I am pretty sure I know what the problem is, and it shouldn't be
a hard fix. I'll try to get to it in the next day or tow.

BTW - even though I have an idea of what the problem might be, I have not
actually confirmed the bug myself. Thus I'm leaving it marked as "unconfirmed."

Comment 5

[Jasper]

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

Comment 6

[Jens Jacob Iversen]

Rather than opening a new bug, here are some more problems probably related to
this bug:

When setting Camino as default browser in the 2005051014 (v0.8+) build the
"General" preferences can not be opened. If Safari or some other browser is set
in Safari as default browser the Preferences opens fine.

If the "Default Web Browser" is changed from Safari to Camino in Safari while
the preferences is open in Camino it is not possible to enter the "General"
preferences but the other preferences opens fine.

I do the Danish L10n of Camino so I have multiple copies of Camino on my drive.
No combination of Default Web Browser and opened Camino copy has worked. 

Comment 7

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

(In reply to comment #2)

> You cannot tell Launch Services to set a particular instance of an application
> as the default. It only takes a bundle ID and then picks whatever instance it
> wants. That doesn't sound like what you're having trouble with, but just in
case...

That sounds exactly like the problem in comment 0--assuming at least one copy of
Camino remains in the trash; if not, it is something else. :-)

BTW, how does Safari manage to handle this a bit better than Camino?  Safari can
distinguish between multiple versions in its UI and in what it tells
LaunchServices to use--i.e., I renamed Camino 0.8.4 to be "CaminoStable" (or
move it to another folder) and set it as default in Safari, I could launch it by
double-clicking on a webloc, even though I could not launch 0.9a1 when 0.9a1 was
set as the default in Safari (because I had at least 0.9a1 build in the trash).

Comment 8

[Jasper]

Please update, if not done I will close this bug.

Comment 9

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

Can anyone still reproduce this?  I used to experience various default-browser issues related to having, or having had, multiple copies of Camino and/or deleting/moving to the trash the copy of Camino set as the default, but I haven't experienced them recently, and I've been unsuccessful when trying to cause them.  But I really don't think the bug miraculously disappeared, unless Apple changed things in LaunchServices in an OS update.

Josh, do you still remember what you thought the problem and fix were (comment 4)?

Comment 10

[Marcello Testi]

Reproduced here with 1.0b1. I put a couple of other older Camino.app around in my HD and the alert showed up, making impossible to set Camino as default browser from Camino itself. Deleting extra Camino.app copies fixed the problem.

Comment 11

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

I just saw this, too, but I can't figure out what steps I performed to cause it, so I can't reproduce it.  I played around with this after Marcello posted that he could repro it, but I couldn't.  

I often have builds in the trash after hunting regression windows, but I usually overwrite yesterday's nightly with today's.  When I saw this, I had the nightly from Nov 8 in the trash, plus Camino 0.8.4 (renamed CaminoStable), and I had recently overwritten the Nov 11 nightly with the Nov 12.

The bug is clearly related to having a copy of Camino in the trash, but that alone is not a sufficient condition to cause the bug.  I've removed the [CLOSE ME] notation and dropped the severity, because the bug is still here but apparently fairly rare, but let's not confirm until we have working steps to reproduce.

Comment 12

[Nick Kreeger]

This is due in part to our current application menu list construction logic. Since we use NSSet's as the data structure for storing our application list, we don't include any duplicates.

Ill fix this after RSS lands...

Comment 13

[Stuart Morgan]

(In reply to comment #12)
> This is due in part to our current application menu list construction logic.
> Since we use NSSet's as the data structure for storing our application list, we
> don't include any duplicates.
> 
> Ill fix this after RSS lands...

If you take a look at the bug where this code was originally written, Josh went from a model which tracked by URL to one that tracked by bundle ID specifically not to allow duplicates.  There's a comment to the effect that he found that LS wasn't honoring the path, and appeared to be operating by bundle ID instead (thus giving users unexepected results by appearing to allow more control than they actually had).  Given that, just allowing duplicate entries may not be the answer.

Comment 15

[Thomas K. (:tom)]

What's the current method to repro, if it's even possible to repro now that we're at 1.5.5 and almost 1.6?

Comment 16

[Stuart Morgan]

This involves confusing Launch Services into deciding that the version of the application with the ID org.mozilla.camino that it knows about doesn't exist. It may be OS-version dependent, but more problematically reproducing it consistently involves getting reproducible behavior out of LS, which is a tall order.

Comment 17

[Thomas K. (:tom)]

I'm kinda wondering if it still exists, after bug 185436 comment 73 showing the new Sparkle update system land on trunk 2007-11-24 12:05:44 PDT.  I believe (but this is anecdotal since "it never happened to me") that it's fixed by moving to the new update system.

And, even if it were to pop up again (for people upgrading to 1.6, since I don't _think_ 1.5.5 uses sparkle), would there be a way to fix it without causing it again in the upgrade to 1.5.6?

I'd like to mark WFM based on anecdotal evidence (hasn't happened to me) and the hypothesis stated above.

Comment 18

[Stuart Morgan]

Sparkle doesn't prevent users from downloading Camino or from throwing copies away, nor does it change the way LS works, so there's no reason at all to believe this to be fixed. When the doctor says "Then don't move your arm like that", it doesn't make the guy's arm better.

We should at least special-case Camino not to be existence-checked. It's still possible that LS would do the wrong thing, but it might not, and at least we wouldn't be showing obviously incorrect information to the user.