696436 - Rename MoCo-generated Aurora and Nightly Mac builds to "FirefoxAurora.app" and "FirefoxNightly.app"

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Justin Dolske [:Dolske]]

Attachment: Screenshot of OS X's dialog

OS X has the unfortunate limitation that you can only have 1 app named "Foo" in your Applications folder (since apps are really just directories named "Foo.app"). This means if you already have a "Foo", then download some other "Foo" and try to put in in Applications, OS X asks you if you want to replace the existing Foo.

As it turns out, there is at least one other OS X app called "Aurora" -- http://www.metakine.com/products/aurora/, and thus conflicts with our "Aurora" channel build of Firefox. If a user has one and then goes to install the other, confusion ensues. (You can of course have both around in different locations, but most users are likely to want their apps to live in the usual spot.)

So, we should resolve this conflict. The minimal change would probably be to just twiddle the bundle name to be unique so they can coexist. Product Marketing, specifically, would like to start using "Firefox Aurora". (See also, bug 659321, where this was previously considered.)

This change should also be done for Nightly, since that sounds just as likely to conflict with someone somewhere. The Beta channel is already just called "Firefox", so no need to change that.

There is no requirement to change the name of existing installs. (To be more specific, unless there's some technical requirement to do so, it's fine to only do this for new builds.)

One issue gavin already mentioned is that if a 3rd party builds from our source right now, it defaults to the "Nightly" branding. We probably don't want such 3rd party builds to prominently feature "Firefox Nightly". So we may need to do some cleverness to allow building as "Nightly" or "Firefox Nightly". Or we could get bug 682414 moving, and default 3rd party builds to that...

Comment 1

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

Attachment: WIP: add support for a bundle prefix

This adds build system support for apps to define a MOZ_APP_MACBUNDLE_PREFIX, used to determine the resulting bundle name. It also cleans up a bit of the browser/app/Makefile.in logic to use a more unique variable name.

The path to our generated bundle seems to be specified in a bunch of places, and I'm not sure I got them all. It'd be nice to consolidate that a little, I'm not sure how feasible that is.

Comment 2

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

Attachment: patch

Cleans up and consolidates the bundle filename selection, and makes it match MOZ_APP_DISPLAYNAME (but with spaces trimmed).

Adds a --with-displayname-prefix configure option that allows adding prefix to MOZ_APP_DISPLAYNAME.

Comment 3

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

Attachment: patch

Changes:

- use less generic sounding variable names in browser/app/
- pre-process the branding.nsi and brand.* files so that they automatically use MOZ_APP_DISPLAYNAME
- AC_DEFINE MOZ_APP_DISPLAYNAME globally
- introduce --with-displayname-prefix flag which allows adding a prefix to MOZ_APP_DISPLAYNAME
- add this flag to the "nightly" mozconfigs with the value "Firefox", so that they get used for Nightly/Aurora builds produced by MoCo (but not otherwise)
- introduce MOZ_MACBUNDLE_NAME variable used for the bundle name, make it the one-true-source for determining the bundle name (used in various places). Its value is MOZ_APP_DISPLAYNAME stripped of spaces (and with an optional "Debug" suffix)

This results in a bundle name of "FirefoxAurora.app", whose displayname is "Firefox Aurora".

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 569830 [details] [diff] [review]
patch

Ted gets to do Mac stuff.

Comment 6

[Justin Dolske [:Dolske]]

Comment on attachment 569830 [details] [diff] [review]
patch

Review of attachment 569830 [details] [diff] [review]:
-----------------------------------------------------------------

General remark: How about updating browser/branding/[official,unofficial] with the same changes made to nightly/aurora? Not so much so we can use --with-displayname-prefix there (although that's nice for purity), but mainly to minimize differences between the different branding flavors. If nothing else, it's easier to do it now and stay in mostly-sync that to wade through it in the future and try to remember if there's a reason for the differences.

Also, nice how much of a cleanup MOZ_MACBUNDLE_NAME results in! :)

::: browser/app/Makefile.in
@@ +250,2 @@
>  #       remove CVS dirs from packaged app
> +	find $(DIST)/$(MOZ_MACBUNDLE_NAME) -type d -name "CVS" -prune -exec rm -rf {} \;

Followup to remove all the CVS cruft?

Comment 7

[Alex Limi (:limi) — Firefox UX Team]

Just to make sure, this means that the Dock item and Application menu are still "Nightly" and "Aurora", not "Firefox Nightly" and "Firefox Aurora", right?

Comment 8

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

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #7)
> Just to make sure, this means that the Dock item and Application menu are
> still "Nightly" and "Aurora", not "Firefox Nightly" and "Firefox Aurora",
> right?

No - the request I received from Liz, based AIUI on discussions with product/engagement, was to change the branding globally. The browser UI and application menu shows "Firefox Nightly" (i.e. brandShortName), and the dock and Cmd+Tab menu show "FirefoxNightly" (since those are based on the bundle filename, apparently).

Comment 9

[Dão Gottwald [:dao]]

(In reply to Gavin Sharp (use [e-mail] for email) from comment #8)
> (In reply to Alex Limi (:limi) — Firefox UX Team from comment #7)
> > Just to make sure, this means that the Dock item and Application menu are
> > still "Nightly" and "Aurora", not "Firefox Nightly" and "Firefox Aurora",
> > right?
> 
> No - the request I received from Liz, based AIUI on discussions with
> product/engagement, was to change the branding globally. The browser UI and
> application menu shows "Firefox Nightly" (i.e. brandShortName),

This is undesirable from a theme point of view. The app button on Windows shouldn't be labeled "Firefox Nightly" and "Firefox Aurora" -- these are too long, both by themselves and in relation to end-user Firefox. This might as well be an issue in other contexts where we expect brandShortName to be... short.

Comment 10

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

(In reply to Dão Gottwald [:dao] from comment #9)
> This is undesirable from a theme point of view. The app button on Windows
> shouldn't be labeled "Firefox Nightly" and "Firefox Aurora" -- these are too
> long, both by themselves and in relation to end-user Firefox.

What are the practical effects of "too long"? Does the button actually render incorrectly, or just look relatively large?

Comment 11

[Dão Gottwald [:dao]]

It's going to look too large and eat away space from the tab strip in maximized windows. So this a) degrades the nightly and aurora user experience and b) means not getting the end-user experience tested in nightly and aurora.

Comment 12

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

(In reply to Justin Dolske [:Dolske] from comment #6)
> General remark: How about updating browser/branding/[official,unofficial]
> with the same changes made to nightly/aurora? Not so much so we can use
> --with-displayname-prefix there (although that's nice for purity), but
> mainly to minimize differences between the different branding flavors.

Yeah, I thought about this, but official/unofficial actually already use different values for MOZ_APP_DISPLAYNAME vs. brand.dtd/properties and branding.nsi, so I couldn't quite consolidate the same way. We should probably do some further cleanup here, but the latest patch doesn't touch branding at all so I'm going to defer this.

> Followup to remove all the CVS cruft?

Will file.

Comment 13

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

Attachment: updated patch

Here's an updated patch that removes some of the changes that aren't strictly needed, and omits the change to MOZ_APP_DISPLAYNAME and brand.dtd/properties. The parameter is now --with-macbundlename-prefix, and it only affects the Mac bundle name.

Comment 14

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

Comment on attachment 575256 [details] [diff] [review]
updated patch

Ted: please review the build/, config/ and configure changes.

John: browser/config/mozconfigs changes are pretty straightforward, and seem to be OK on try, but just want to confirm that changing the Mac bundle name like this won't bust anything from a releng point of view (including things like nightly updates, etc.).

Comment 15

[John Ford [:jhford] CET/CEST Berlin Time]

Comment on attachment 575256 [details] [diff] [review]
updated patch

I don't think this is going to break us.  For unit tests and talos we use find to make sure we don't need to hardcode bundle names [1][2].  I don't think we care about the bundle name for nightlies, those work purely with mars [3].  Since we don't have any release automation off those branches, we don't need to worry about release automation.


[1] http://hg.mozilla.org/build/buildbotcustom/file/36c8c6de903f/process/factory.py#l6330
[2] http://hg.mozilla.org/build/buildbotcustom/file/36c8c6de903f/process/factory.py#l7119
[3] http://hg.mozilla.org/build/buildbotcustom/file/36c8c6de903f/process/factory.py#l2242

Comment 16

[(not currently active) Ted Mielczarek]

Comment on attachment 575256 [details] [diff] [review]
updated patch

Review of attachment 575256 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the review delay. Just a few comments.

::: browser/app/Makefile.in
@@ +211,3 @@
>  
>  ifdef MOZ_DEBUG
> +MAC_APP_NAME := $(MAC_APP_NAME)Debug

Feels weird to duplicate this logic here after you consolidated it into configure.

::: browser/app/macbuild/Contents/Info.plist.in
@@ +149,4 @@
>  	<key>CFBundleIconFile</key>
>  	<string>firefox</string>
>  	<key>CFBundleIdentifier</key>
> +	<string>org.mozilla.%LOWER_MAC_APP_NAME%</string>

Do we really need to change the bundle identifier? Surely this isn't going to conflict with anything.

::: browser/config/mozconfigs/linux32/nightly
@@ +23,5 @@
>  
>  #Use ccache
>  ac_add_options --with-ccache=/usr/bin/ccache
> +
> +ac_add_options --with-macbundlename-prefix='Firefox'

Is there a reason these have quotes?

::: toolkit/mozapps/installer/packager.mk
@@ +347,5 @@
>    rm -rf lib
>  endif
>  ifeq ($(MOZ_PKG_FORMAT),DMG)
>  ifndef _APPNAME
> +_APPNAME	= $(MOZ_MACBUNDLE_NAME)

Just kill the tab in this line while you're here.

Comment 17

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

(In reply to Ted Mielczarek [:ted, :luser] from comment #16)
> >  ifdef MOZ_DEBUG
> > +MAC_APP_NAME := $(MAC_APP_NAME)Debug
> 
> Feels weird to duplicate this logic here after you consolidated it into
> configure.

This is actually slightly different - there's no .app here, and I'm just preserving the previous behavior of having the plist app/bundle name include the Debug suffix.

> > +	<string>org.mozilla.%LOWER_MAC_APP_NAME%</string>
> 
> Do we really need to change the bundle identifier? Surely this isn't going
> to conflict with anything.

This also isn't changing any behavior - I'm just renaming the variable since APP_NAME is difficult to grep for.

> Is there a reason these have quotes?

Guess not! I'll omit them. I also locally changed this so that the flag is only added to Mac configs (since it's now Mac-specific).

Comment 18

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

Attachment: updated patch

I just pushed this to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9e94c7b5290f

Comment 19

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

I need to land this on Aurora for it to take effect there (the main motivation for this bug, see comment 0). This changes the produced bundle name from Aurora.app to FirefoxAurora.app, but only for builds produced using the in-tree configs (i.e. those produced by the MoCo build infra).

There should be no other code impact. The actual config changes only apply to Nightly and Aurora builds (i.e. those built using the "nightly" mozconfigs).

Comment 20

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Backed out due to test-run bustage on Mac opt:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7a510c246bf2

Bustage:
https://tbpl.mozilla.org/php/getParsedLog.php?id=7968828&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=7968932&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=7968752&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=7968770&tree=Mozilla-Inbound
etc etc

Comment 21

[Phil Ringnalda (:philor)]

Relanded in https://hg.mozilla.org/integration/mozilla-inbound/rev/6b18f5259de9 with this convoluted theory:

We were red for your push and two of the sixteen pushes above you, so backing out was the right thing to do.

Then, we were green for two pushes above that, oh yeah, changing names like this requires a clobber.

Now we've got slaves with both names in their objdir, planning on screwing up things either way, so we have to clobber, and we're pretty sure clobbering will clear it up since it already did twice, so better to gamble and get it relanded than to have to take yet another clobber, and yet another tree closure to ensure it's the one that gets the clobber, to get it landed.

Comment 22

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/9e94c7b5290f
https://hg.mozilla.org/mozilla-central/rev/7a510c246bf2
https://hg.mozilla.org/mozilla-central/rev/6b18f5259de9

Comment 23

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

Attachment: aurora patch

This is merged to aurora, with the fix for bug 711478 included.

Comment 24

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

I'd like to land this before Monday, because apparently some kind of Aurora marketing campaign is launching then, and the Metakine folks would appreciate if those builds didn't clobber their application.

Comment 25

[Alex Keybl [:akeybl]]

Comment on attachment 582319 [details] [diff] [review]
aurora patch

[Triage Comment]
Given product marketing's OK, let's land on Aurora.

Comment 26

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/bd759f82e517

Comment 27

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

NOTE TO SELF AND ANY INTEGRATION BRANCH MERGERS WHO MIGHT SOMEHOW NOTICE THIS:
Landing this patch required clobbering Mac builds.

Comment 28

[Alex Limi (:limi) — Firefox UX Team]

There are a couple of issues with this after landing:

* The name of the application is "FirefoxNightly" instead of "Firefox Nightly" (it should be the latter)

* The default position of the icon is not lined up properly, so the text becomes unreadable, and it looks asymmetrical. Will attach screenshots.

Comment 29

[Alex Limi (:limi) — Firefox UX Team]

Attachment: Screenshot after patch is applied, shows the unaligned icon + lack of space in the name

Comment 30

[Dão Gottwald [:dao]]

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #28)
> There are a couple of issues with this after landing:
> 
> * The name of the application is "FirefoxNightly" instead of "Firefox
> Nightly" (it should be the latter)
> 
> * The default position of the icon is not lined up properly, so the text
> becomes unreadable, and it looks asymmetrical. Will attach screenshots.

Please file new bugs for both of these issues.

Comment 31

[Daniel Holbert [:dholbert] (mostly-away until Aug 19)]

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #28)
> * The default position of the icon is not lined up properly, so the text
> becomes unreadable, and it looks asymmetrical. Will attach screenshots.

I independently ran into this misaligned-icon issue and filed bug 714951 on it.

Comment 32

[Justin Dolske [:Dolske]]

(In reply to Dão Gottwald [:dao] from comment #30)

> > * The name of the application is "FirefoxNightly" instead of "Firefox
> > Nightly" (it should be the latter)
> > 
> > * The default position of the icon is not lined up properly, so the text
> > becomes unreadable, and it looks asymmetrical. Will attach screenshots.
> 
> Please file new bugs for both of these issues.

For those playing along at home...

Bug 715619 for the former, bug 714951 for the latter.

Comment 33

[Mihaela Velimiroviciu (:mihaelav)]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0a2) Gecko/20120109 Firefox/11.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0a2) Gecko/20111219 Firefox/10.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0a1) Gecko/20120109 Firefox/12.0a1
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0a1) Gecko/20111219 Firefox/11.0a1

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a2) Gecko/20120109 Firefox/11.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111219 Firefox/10.0a2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111219 Firefox/11.0a1

Verified the change with the above builds and the names of Aurora and Nightly in Applications are FirefoxAurora, respectively FirefoxNightly.

Still, if an older Aurora version (since before the name change, e.g. Dec 1 2011) is updated to a newer one (e.g. latest version), the name in Applications remains "Aurora" (it is not updated to "FirefoxAurora"). Is this desired?
Example: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111201 Firefox/10.0a2 updated to Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a2) Gecko/20120109 Firefox/11.0a2  keeps the old "Aurora" name in Applications

Comment 34

[Mihaela Velimiroviciu (:mihaelav)]

(In reply to Mihaela Velimiroviciu [QA] from comment #33)
> Verified the change with the above builds and the names of Aurora and
> Nightly in Applications are FirefoxAurora, respectively FirefoxNightly.
 
... at new install.

Comment 35

[u279076]

I believe this can be marked verified fixed. If the folder not being renamed is unexpected, it can be filed in a new bug. Though I suspect it is expected behaviour. I don't think we are in the habit of renaming program level folders when updating.