Cannot set Firefox 109 beta as default browser in macOS (older versions do work)
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
People
(Reporter: fv8l1rxj1, Unassigned)
Details
I cannot set Firefox 109 beta as default browser in macOS 12.6 any longer. I can set in the system preferences or let Firefox set it for me on start but even if set there and even is correctly stored on the system preferences, HTTP/HTTPS URLs will open in Safari instead.
This is the content of com.apple.launchservices.secure.plist:
30 => {
"LSHandlerPreferredVersions" => {
"LSHandlerRoleAll" => "-"
}
"LSHandlerRoleAll" => "org.mozilla.firefox"
"LSHandlerURLScheme" => "http"
}
But HTTP opens with Safari. Reboot of the system doesn't help. Selecting another browser does work. If I select TOR, HTTP opens with TOR, if I select Safari, it opens with Safari but if I select Firefox, it opens also with Safari.
So I downloaded Firefox 108 and setting this version to default works as expected. However, now I can only set this version. If I try to select "Firefox (109.0)", the selection immediately jumps back to "Firefox (108.0)". So the problem is only with version 109, no problem with version 108. If 108 is set, HTTP URLs will open with 108. When I delete 108 again, I can set 109 again but when I try to open an URL, it opens in Safari.
And I guess I found the problem. The output of the com.apple.launchservices.secure.plist above was actually when Firefox 108 was set. When I set it to 109, the correct output is:
30 => {
"LSHandlerPreferredVersions" => {
"LSHandlerRoleAll" => "10823.1.4"
}
"LSHandlerRoleAll" => "org.mozilla.firefox"
"LSHandlerURLScheme" => "http"
}
Note: "LSHandlerRoleAll" => "10823.1.4"
When I set Safari, TOR or Firefox 108, LSHandlerRoleAll is always "-" but when I set it to Firefox 109, LSHandlerRoleAll is 10823.1.4
I'm not sure what LSHandlerRoleAll is good for, I cannot find any documentation about it, but in all samples I've seen so far this key either contains just "-" or a reverse domain name or an app name, I found no sample where it would ever contain a number.
Comment 2•3 years ago
|
||
Please do not set the Priority or the Severity fields, as indicated in the Etiquette Guidelines, Section "Changing Fields", point 1.
Comment 3•3 years ago
|
||
Shell Integration (admittedly confusingly) doesn't tend to handle MacOS issues.
haik: Is Widget: Cocoa the appropriate place for this or would you prefer it elsewhere?
Updated•3 years ago
|
Comment 4•3 years ago
|
||
This is most likely an unfortunate consequence of the fact that we intentionally keep beta and release builds as identical as possible in order for our beta population to test release candidates before we publish them to the release channel. This means that identifiers such as "org.mozilla.firefox" will be the same between beta and release and macOS doesn't have a way to differentiate between the two. If you remove other app bundles on your system with the same identifier (any other release or beta versions of Firefox) you should find that you can now set Firefox 109 beta as your default browser. Could you confirm that this is indeed the case?
I only had one copy of Firefox on my entire system and nothing else and that was a beta copy. When this copy got updated to the last beta previous to the final release I would start Firefox and it would prompt me whether I want to set it as default browser, despite the fact that it always has been default up to this point. So I said yes and relaunched the app, just to see the question coming up again. No matter how often I agreed, went to the preferences in in Firefox and selected to become default browser or select Firefox in the System Preferences, it would not become default an all URLs would open with Safari. Only then I went to mozilla.org to get the last official release version, only then I had two copies on the system and noticed, that I can set the official release default but not the beta. Then I located where macOS stores that information and posted what I came up with. Meanwhile I have deleted the release version again and my only copy on the entire system is 110.0b4 and I can set this version to default as I used to. But before that ability definitely broke by just updating to the latest beta, there was no other change on my system in between. I set the priority as I considered this to be a serious issue and basically a release blocker in case that would have been an issue also with the release version as then shipping that version would have broken default browser setup for how many thousand users? It didn't happen with the final release but that I couldn't test, as the latest beta was as close to the final release as I could get. So I don't know how it broke and why it didn't happen with the final release but it did not break because I had more than one copy of Firefox on my system (not unless the updater botched something).
Comment 6•3 years ago
|
||
Interesting. Are you able to find the build that exhibited this behavior in the Firefox archives here? https://ftp.mozilla.org/pub/firefox/releases/ If you download and install the build from the archives, does the issue reproduce that you reported? If so, could you post the link to the build?
Should have been the last beta of 109, so https://ftp.mozilla.org/pub/firefox/releases/109.0b9/
It was auto-installed, so I don't know for sure if it was the build but if there has ever only been one build with that version number, then that must be the build.
Testing is always kinda annoying, as I never can use my profile and new profiles are created in the wrong location. I don't know of any other app that refuses to keep using a profile just because of a small downgrade or switch between beta and release track (I do that with other apps all the time). But I did replace my current beta with that one by hand and that didn't show the problem again, yet I cannot say if that is exactly the same state I got after the auto-update.
First I thought the problem has something to do with my a bit unusual setup, as Firefox.app is not located on my main drive but on a partition of a secondary drive where I keep most of my apps; that's because the main drive is in fact an external drive and the secondary drive is the real internal drive (the internal one is faster but I need the boot system on an external drive). Also my profile is located on the secondary drive and referenced by absolute path in the profiles.ini file. Yet this has never been an issue so far.
Then I thought the problem may be related to having installed the TOR browser a few days before but deleting it made no difference. And as said before, I did reboot my system multiple times, also after deleting TOR browser, that made no difference either.
It got fixed by deleting the two copies of Firefox I ended up with during testing (the 108 release I installed for testing and the not working 109b9) and then installing the 109 release version once it came out (in the meantime I had to live without Firefox being the default browser) and that one worked normally again. Meanwhile I'm back on the beta track having manually installed a 110 beta version, which is now again the only remaining copy of Firefox on my system.
Comment 8•3 years ago
|
||
Okay, then let's close this bug for now and reopen if this occurs again.
Updated•3 years ago
|
Description
•