Closed Bug 387834 Opened 12 years ago Closed 10 years ago
Minefield steals default browser preference/setting from Bon Echo/branch builds
Summary: Minefield steals default browser preference/setting from Bon Echo/branch builds Build ID: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/2007071104 Minefield/3.0a7pre I'm marking this as critical because it's impeding me from successfully testing point releases. Steps to Reproduce: 1. Install a trunk version of Firefox (Minefield) 2. Set it as the default browser 3. Install 126.96.36.199 or a 188.8.131.52 candidate 4. Set the branch build as the default browser (verify that it's set via inspecting the value in Safari's "Preferences | Default Web Browser" pull-down field) 5. Shut down all browsers 6. Open Thunderbird or some other application and clink on a link Expected Results: Bon Echo or the 184.108.40.206 candidate opens Actual Results: Minefield stubbornly decides to override, launching itself as the browser Additional Info: Both Minefield and Bon Echo share the "[Application Name is already set as your default browser]" setting. I've tried: A couple different machines, as well as completely removing and reinstalling the builds, to no avail. I even tried a separate folder within / out of the "Applications" folder, but that didn't ameliorate the issue. I scoured OS Integration and didn't find something that covered this case, largely because this is likely to be experienced only by folks testing both trunk and branch concurrently (in-house).
This is a bug in OS X, as far as I can tell. I have to use Safari 2 (ugh!) as my default browser because the OS refuses to give me a clean way to make each successive trunk build of Firefox or Safari be my default browser.
Indeed, I think this is a problem with OS X's default browser handling. I used to run into all sorts of problems when running both Minefield and Bon Echo and trying to keep Bon Echo my default. Running minefield-only seems to have taken care of that to some degree. It also seems to favor "Firefox" branded builds above all else.
Anyone had luck with http://www.rubicode.com/Software/RCDefaultApp/ ?
Well, it's a limitation of OS X's protocol handling, not really a bug. When you register an application to handle a URL type (i.e. http), the system registers the CFBundleIdentifier key from the application's Info.plist. If two apps have the same bundle ID, then the OS thinks they're equivalent. I don't know the intimate details of how it resolves when there's more than one app, but I imagine that it takes into account date and version, at the very least. We could have unique bundle IDs, such as @"org.mozilla.minefield" and @"org.mozilla.bonecho" for unbranded builds, but the bundle ID is used all over the place for a lot of different things, I'm not sure changing it is a good idea.
I actually think this is partly a bug in the way that Moz browsers set the default browser, though I don't think anyone agrees with me ;) In Safari's default browser menu, it lists multiple copies of a given browser if you have them, followed by the (version number in parens) in that case. When I set one of these versions (in my case, of Camino) as default, LaunchServices launches that version of Camino, even if a higher version is actually a newer (date/installed later) app, when I open a .webloc or whatever. If you have two copies of that version, it's still roulette among copies of that version (maybe the official nightly, maybe my own build), but that's not the issue here. By contrast, in Camino we only list one copy of an app and have a few bugs like bug 289020, which has a bit of Jesse's comment 1 in it (Firefox has no menu at all, but I assume it uses a similar method to Camino when setting itself as default). All the comments in bug 289020 indicate I'm wrong, but I still don't know how Safari is able to distinguish between versions and instruct LaunchServices to do so as well, unless it's also passing a version number (or successfully using the path method that wasn't working for us).
Sorry for the delay, and thanks for everybody's helpful comments. TBH, I'm really not sure what to do with this bug: keep it open (so that folks looking to file a bug who've searched will find the issue and get an answer), or just close it as WONTFIX (INVALID might be the wrong resolution, given that we _could_ do the "whole lotta pain" thing Colin mentions in comment 4...
Downgrading, since this is well-know. Lo siento para el spamo.
Severity: critical → minor
Something we can do on that issue for Firefox.next? It's really annoying while testing release builds on OS X.
That's not a reason to keep Firefox 3.6 from being shipped to millions of users, it's a reason for you to find someone to help you diagnose and solve the problem.
Flags: blocking-firefox3.6? → blocking-firefox3.6-
(In reply to comment #10) > That's not a reason to keep Firefox 3.6 from being shipped to millions of > users, it's a reason for you to find someone to help you diagnose and solve the > problem. Mike, that's not a problem only on my box. Everyone who has installed Minefield runs into this trouble. It's clearly a bug which makes our life hard while running the smoketests on OS X. It would require us to always use a fresh OS X user profile. Fall-outs are issues like bug 522369. CC'ing Steven and Markus who both will have more knowledge about the system default registration of applications.
I don't know what (if anything) we can do about this. I believe Colin's comment #4 is accurate. In other words, if two apps have the same CFBundleIdentifier (as all versions of FF do), the OS picks one more or less at random to make the default app. Smokey's comment #5 is interesting. If he's right, we may be able to do something to improve the situation. But that'll require a lot of digging into undocumented stuff. Which I know is my forte :-) But I also have lots of other things to work on.
(In reply to comment #12) > Smokey's comment #5 is interesting. If he's right, we may be able to > do something to improve the situation. But that'll require a lot of > digging into undocumented stuff. Safari doesn't seem to be able to convince LaunchServices to actually open the version selected now; I believe I've noted elsewhere that the behavior I described in comment 5 was only true on 10.3.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 553073
You need to log in before you can comment on or make changes to this bug.