554997 - change of CFBundleIdentifier breaks default browser setting and Spaces integration

Status: RESOLVED WORKSFORME

(Firefox :: Shell Integration, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

See bug 553073 comment 8 and following comments. Seems like the change in bug 553073 has the potential to cause problems on update, though maybe that's only true if you have multiple versions of Firefox/Minefield installed?

Comment 1

[LegNeato]

What does running /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
-dump give you? Likely it is because of the existing launchservices database and it merely needs to be rebuilt.

Note if this is the case it would only happen when updating from a pre- bug 553073 build to a post- bug 553073 build. It should only affect Minefield as well, not branded Firefox builds.

Comment 2

[LegNeato]

BTW, moving the app around as in bug 553073 comment 12 is essentially tricking LaunchServices into reloading information. It can probably be fixed by running "/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -all" as well, though I am not 100% positive of the other ramifications of doing so.

Comment 3

[LegNeato]

It's even easier, just do:

touch /Applications/Minefield.app

Before doing that, LaunchServices still had the incorrect identifier for Minefield and wasn't updating the cache with what was on disk. Once you do the touch, the lsdatabase is updated and setting minefield as the default works and sticks.

Comment 4

[LegNeato]

We could have this bug tracking the automatic "touch" of the firefox/minefield app bundle after an install. The Mac OS X Installer and Software Update do that automatically for their updates. Because we don't use that mechanism we need to do it ourselves.

Note that the installer touches every bundle in the package. I'm not sure if we want to touch the sub-bundles of the .app as well. Most of them don't have unique identifiers which has the potential to cause issues running Firefox/Minefield side-by-side. I'll investigate a bit.

Comment 5

[Nomis101]

You will find a touch script in a few Apple install packages, e.g. iWorks or iLife in the postflight_actions folder. For iWorks09 this looks like:

> # Nudge the filesystem to make things update faster
> system("/usr/bin/touch", "-c", "$3/Applications/iWork '09/Pages.app");
> system("/usr/bin/touch", "-c", "$3/Applications/iWork '09/Numbers.app");
> system("/usr/bin/touch", "-c", "$3/Applications/iWork '09/Keynote.app");
> system("/usr/bin/touch", "-c", "$3/Applications/iWork '09/");
> system("/usr/bin/touch", "-c", "$3/Applications");

So the installer touches first the installed application and than the Applications folder.

Comment 6

[Ashley Bischoff (blog at handcoding.com)]

Is bug 554865 a dupe of this?

Comment 7

[LegNeato]

(In reply to comment #5)
> You will find a touch script in a few Apple install packages, e.g. iWorks or
> iLife in the postflight_actions folder. For iWorks09 this looks like:
> 
> > # Nudge the filesystem to make things update faster
> > system("/usr/bin/touch", "-c", "$3/Applications/iWork '09/Pages.app");
> > system("/usr/bin/touch", "-c", "$3/Applications/iWork '09/Numbers.app");
> > system("/usr/bin/touch", "-c", "$3/Applications/iWork '09/Keynote.app");
> > system("/usr/bin/touch", "-c", "$3/Applications/iWork '09/");
> > system("/usr/bin/touch", "-c", "$3/Applications");
> 
> So the installer touches first the installed application and than the
> Applications folder.

Yep, and in Snow Leopard and later the installer does that automatically. Some teams at Apple may not have updated their packaging or need to install on Tiger -> Snow Leopard so they do the touch to be safe.

Comment 9

[LegNeato]

You can do:

$
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
-dump | grep -iC 10 mine | grep -c org.mozilla.firefox

(Snow Leopard)

$
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
-dump | grep -iC 10 mine | grep -c org.mozilla.firefox

(Leopard)

If you get anything more than zero, your LS database is out of date and can hit
this bug.

Comment 10

[Nomis101]

What are the differences between the Snow Leopard argument and the Leopard one? For org.mozilla.firefox I've get a value of 5 and for org.mozilla.thunderbird "0". But thats, because for TB I use an install script and for FF simple drag&drop.

Comment 11

[LegNeato]

Ack, sorry. lsregister changed paths between Tiger and Leopard. I wasn't thinking and copied in the same thing thinking the change was between Leopard and SnowLeopard.

And here is a slightly more robust command:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump | grep -C 2 Minefield.app | grep -c 'identifier:    org.mozilla.firefox'

Basically you can look at the Minefield.app entry in 'lsregister -dump', if it has org.mozilla.firefox instead of org.mozilla.minefield then your database needs to be updated/the workaround applied.

Comment 13

[Mark Banner (:standard8)]

Oh btw, I think this should probably block the first beta from 1.9.3... the reason being is that will be branded Firefox, and anyone upgrading from an alpha is going to hit this issue again (using automatic update on the beta channel).

Comment 14

[Michael]

The bug has returned with the latest Minefield build...

Comment 15

[LegNeato]

(In reply to comment #13)
> Oh btw, I think this should probably block the first beta from 1.9.3... the
> reason being is that will be branded Firefox, and anyone upgrading from an
> alpha is going to hit this issue again (using automatic update on the beta
> channel).

Only people updating from an alpha with the improper "firefox" id will see this issue I believe. The fix for bug 553073 has been in the last 2 alphas (afaik) so those users won't see this (assuming they weren't running a previous alpha). Also people going from the beta -> final won't see the issue at all.

Basically the only people affected by this are those installing nightlies from before / after bug 553073 came in and those who installed an old alpha and then later update to the beta. If they went from old alpha -> less old alpha with bug 553073 fixed then they have already seen the issue.

Comment 16

[LegNeato]

Now that I think about it, users might prompt going from alpha->beta. If they had the alpha ("org.mozilla.minefield") set as default and the beta auto-updates them to "org.mozilla.firefox" there may be an issue. But will they still be running Minefield.app or Firefox.app? If it changes to Firefox.app I think we're fine, if it stays Minefield.app there might be issues.

Manual installs of the beta over the alphas/dev previews should be fine as the apps are named differently. They can actually be run side-by-side, which was the point of fixing bug 553073.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

I don't think the updater changes the bundle name...

Comment 18

[Robert Strong (they/them - no direct email)]

Don't think this affects anything besides Mac OS X so changing platform... please give details if I am wrong in this belief.

Also, I don't think there is much if anything the Mac installer can do here whereas the Mac shell integration code should be able to detect the change and do the right thing I would hope.

Comment 19

[LegNeato]

Whoops, sorry rs. Saw comment 7 and got ahead of myself, we don't use the installer mechanism on Mac.

nthomas said the alphas were MozillaDeveloperPreview.app
("org.mozilla.mozilladeveloperpreview"). If we update those users to beta and the
auto-updater doesn't change the containing .app bundle to Firefox.app (or alter
the mtime?), all the alpha users will see this bug.

Comment 20

[Robert Strong (they/them - no direct email)]

The updater could be taught by someone to change the mtime for Mac OS X... is that what you are asking for? If so, that is bug 314794. I'd suggest either moving this bug back to shell integration and making it dependent of that bug or duping this bug to that bug.

Comment 21

[Mark Banner (:standard8)]

(In reply to comment #16)
> Now that I think about it, users might prompt going from alpha->beta. If they
> had the alpha ("org.mozilla.minefield") set as default and the beta
> auto-updates them to "org.mozilla.firefox" there may be an issue. But will they
> still be running Minefield.app or Firefox.app? If it changes to Firefox.app I
> think we're fine, if it stays Minefield.app there might be issues.

We don't change the name of the app bundle. Which is why I think there may be issues here.

> Manual installs of the beta over the alphas/dev previews should be fine as the
> apps are named differently. They can actually be run side-by-side, which was
> the point of fixing bug 553073.

Yes, it is purely all the upgraders from previous alphas that have this that will be affected.

Comment 22

[Robert Strong (they/them - no direct email)]

Since no reply to comment #20 moving back to shell integration since this is actually a shell integration bug.

Comment 25

[LegNeato]

Ack. We can't just dupe this because even if we fixed it the installer wouldn't
apply the fix until after the beta. We need this fixed on app startup or
something similar.

Comment 26

[Robert Strong (they/them - no direct email)]

So, there is a problem when installing via the dmg and not just when updating (bug 314794)? iirc there is the ability to run a script from the dmg but it might be simpler to have the Mac shell integration code detect when there is a change and then do what is necessary.

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

Not sure that this needs a relnote, but do think we need to fix before final.

Comment 28

[Johnathan Nightingale [:johnath]]

dolske pinned this to bug 600098, but I'm wondering whether the changes we make there will obviate this bug completely, or whether there is separate work to do here?

Comment 29

[Robert Strong (they/them - no direct email)]

As I understand it

This identifier is used to identify Firefox as the default browser and is not seen by the user. With bug 553073 fixed the identifier can change either by a new install with the same bundle name or an app update and at that point Firefox is no longer the default browser. On Windows we have identifiers for Firefox as well to determine the default browser and they are the same for all builds to avoid this type of issue in its entirety.

I was able to reproduce the "Unknown Application" issue in spaces and after applying an empty update with the fix from bug 600098 it displayed Minefield. When the CFBundleIdentifier changes the user is prompted to set Minefield / Firefox / etc. as the default browser even if it was the default prior to the change to CFBundleIdentifier as long as the pref to check if Firefox is the default browser is true. to fix that would require an external app that is launched after a successful update similar to what we already have for Windows.

Comment 30

[Dietrich Ayala (:dietrich)]

Been two months with no action. Rob, can you or someone who knows what needs to be done describe what needs to be implemented for this?

Comment 31

[Robert Strong (they/them - no direct email)]

My comments were from trial and error testing to try to understand what is going on / needs to be done. As I understand it, bug 553073 made it so nightly builds use a different CFBundleIdentifier than release builds. From my testing, bug 600098 made it so the Unknown Application issue in spaces is fixed after an update along with the rest of what I stated in comment #29.

I don't know if there is anything else that needs to be done for the Mac shell integration code at this time. I suspect we are in decent shape at this time but it would be a good thing if someone more familiar with Mac idiosyncrasies took a look at the current behavior.

One thing to keep in mind is that if we were to change the CFBundleIdentifier for nightly or release builds (for example, bug 553073 changed them for nightly builds) it would be a good thing to have a separate native app specified in the updater.ini which will be launched after a successful app update to verify / update the default browser settings. If the CFBundleIdentifier is not changed for the install then this should not be an issue.

Comment 32

[Dietrich Ayala (:dietrich)]

(In reply to comment #31)
> My comments were from trial and error testing to try to understand what is
> going on / needs to be done. As I understand it, bug 553073 made it so nightly
> builds use a different CFBundleIdentifier than release builds. From my testing,
> bug 600098 made it so the Unknown Application issue in spaces is fixed after an
> update along with the rest of what I stated in comment #29.

This almost sounds like this bug is WFM. Adding QAWanted keyword to get some comprehensive testing to figure out if this is still a problem or not.

Comment 33

[Robert Strong (they/them - no direct email)]

If I understand what happens with this bug correctly (I very well might not) this occurs when the CFBundleIdentifier changes which we are not planning on doing anytime soon if ever (the report is regarding nightly users which did change CFBundleIdentifier). So, I don't think this needs to block.

Comment 34

[Johnathan Nightingale [:johnath]]

Josh, per Rob's request for a mac-specialist to comment in comment 31, do you agree with his comment 33? :)

Comment 35

[:Gavin Sharp [email: [e-mail]]]

The issue is the change between Firefox 3.6.x and Firefox 4, on upgrade.

Comment 36

[Robert Strong (they/them - no direct email)]

Isn't is actually the same for release builds? The patch in bug 553073 has the following:
-	<string>org.mozilla.firefox</string>
+	<string>org.mozilla.%LOWER_APP_NAME%</string>

Which I believe will be org.mozilla.firefox for release builds. Also, the bundle name would follow %LOWER_APP_NAME% as well (e.g. minefield.app = org.mozilla.minefiled, whatever.app = org.mozilla.whatever, etc.)

Comment 37

[juan becerra [:juanb]]

I have been trying a lot scenarios trying the steps to reproduce from duplicate bugs, and I can't get the problem to happen. When I set a browser instance to be the default browser, whether it be Namoroka, Firefox 3.6x, Minefield, MozillaDeveloperPreview, Fx4beta, older or newer, the setting is preserved. The application is associated with a Space and stays that way. During my testing never did links from external apps try to open in Safari if I had setup any of the nightlies or Firefox as the default browser. I tried update combinations as well. 

The only thing I noticed was that if I had set Minefield as my default browser, while running also a Namoroka instance, and I quit the Minefield instance, all links from external applications open in the running instance, Namoroka. If I closed both browsers and tried to open a link from an external app, it would launch the correct one, Minefield.

If know of the simplest scenario I could try to check this against, please let me know. I did not try to create a dummy mar file I could apply to one of the 3/25 builds to see the problem.

Comment 38

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #36)
> Isn't is actually the same for release builds? The patch in bug 553073 has the
> following:
> -    <string>org.mozilla.firefox</string>
> +    <string>org.mozilla.%LOWER_APP_NAME%</string>

Right, current beta releases show up '<string>org.mozilla.firefox</string>' as bundle identifier.

The only situation I can see when the default browser cannot be set, is when the user has installed the beta in parallel to any older release. As far as I get the information from this bug, the default application is identified by the bundle identifier. This will limit us to only set the beta or the older release build as the default browser. Clicking on 'Check now' in the advanced pref pane will then always return that the current application is the default application.

I did some checks for upgrades/downgrades and Minefield installed in parallel. Checking for the default browser works fine for me.

(In reply to comment #37)
> The only thing I noticed was that if I had set Minefield as my default browser,
> while running also a Namoroka instance, and I quit the Minefield instance, all
> links from external applications open in the running instance, Namoroka. If I
> closed both browsers and tried to open a link from an external app, it would
> launch the correct one, Minefield.

Same here, but isn't that an issue which is already present for a while?

Comment 39

[Dietrich Ayala (:dietrich)]

Comment #37 and comment #38 indicate that the problem is not reproducible -> WFM.

(In reply to comment #38)
> (In reply to comment #37)
> > The only thing I noticed was that if I had set Minefield as my default browser,
> > while running also a Namoroka instance, and I quit the Minefield instance, all
> > links from external applications open in the running instance, Namoroka. If I
> > closed both browsers and tried to open a link from an external app, it would
> > launch the correct one, Minefield.
> 
> Same here, but isn't that an issue which is already present for a while?

Is there already a bug for it? I don't think we'd block on this particular issue, since the setting isn't really broken and it's difficult for normal users to actually get into it. (Nominate that bug for blocking if I'm wrong about that.)