659321 - Allow adding "Firefox " prefix to branding displaynames

Status: RESOLVED DUPLICATE of bug 696436

(Firefox Build System :: General, defect)

Description

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

"product marketing" want the builds that we ship to be branded "Firefox Nightly", "Firefox Aurora", and "Firefox Beta", instead of the current names (without "Firefox ").

We have to do this while keeping in mind the following constraints:
1) We want to ensure that people who build with default configs get a
trademark-free browser.
2) We want to ensure that people building from our release branches
get a suitably-branded browser (e.g. building from the tip of
mozilla-aurora gets you a build that's distinguishable from a build
built from the tip of mozilla-central).

Proposed solutions:
a) Switch "Nightly"/"Aurora" to "Firefox Nightly"/"Firefox Aurora"

This solution is simple, but it fails to satisfy 1).

b) Introduce a new trademark-free branding (e.g. "Browser"), use that
for the default branding, and then just have MoCo build configs specify
the alternate brandings for the builds we produce

This satisfies 1), but does not satisfy 2).

c) Keep the current branding setup, but add a build flag that allows
adding a "Firefox " prefix to the brand name for the alternate
brandings (Nightly/Aurora and possibly Beta). MoCo build configs would
pass that flag for the builds that we produce.

I think c) is feasible, but might introduce complications with l10n.

Comment 1

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

So my l10n concern was that having a hardcoded prefix isn't friendly to the locales that localize brandShortName, but given that this will only apply to Nightly/Aurora, whose branding directories aren't localized, I think it's probably fine.

Comment 2

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

Attachment: patch

This patch adds a --with-displayname-prefix configure argument that allows prepending a string to MOZ_APP_DISPLAYNAME. When this flag is passed, the value of MOZ_APP_DISPLAYNAME is changed (prefix is added, without a space), and two additional variables are defined: MOZ_APP_DISPLAYNAME_PREFIX (the passed-in prefix, unquoted) and MOZ_APP_DISPLAYNAME_SUFFIX (the old value of MOZ_APP_DISPLAYNAME, i.e. without the prefix, also unquoted).

In addition to that, this patch has some changes to Firefox's aurora and nightly branding directories:
- makes brand.dtd, brand.properties use the value of those variables accordingly (can't use DISPLAYNAME directly since it doesn't contain spaces)
- adjusts how branding.nsi is copied to dist/branding such that it gets preprocessed, so that it too can use the variables

Comment 3

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

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

The idea here is that we would leave the current branding setup as-is, but have the MoCo build configs specify --with-displayname-prefix=Firefox.

Comment 4

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

I think we should hold off on this until a final decision is made.

Comment 5

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

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

># HG changeset patch
># User Gavin Sharp <[e-mail]>
># Date 1306256382 14400
># Node ID b79fc75fa8d48848cb0f9e720ff8fbd72e098939
># Parent  acb4e51fa8a6c6d4d6f13a6fee31f88c293387e7
>Bug 659321: add --with-displayname-prefix configure flag to allow prefixing the displayname
>
>diff --git a/browser/branding/aurora/Makefile.in b/browser/branding/aurora/Makefile.in
>--- a/browser/branding/aurora/Makefile.in
>+++ b/browser/branding/aurora/Makefile.in
>@@ -48,17 +48,16 @@ DIRS = \
> 
> PREF_JS_EXPORTS = $(srcdir)/pref/firefox-branding.js
> 
> include $(topsrcdir)/config/rules.mk
> 
> WINDOWS_BRANDING_FILES = \
> 	firefox.ico \
> 	document.ico \
>-	branding.nsi \
> 	wizHeader.bmp \
> 	wizHeaderRTL.bmp \
> 	wizWatermark.bmp \
> 	$(NULL)
> 
> ifdef MOZ_SPLASHSCREEN
> WINDOWS_BRANDING_FILES += splash.bmp
> endif
>@@ -82,16 +81,17 @@ LINUX_BRANDING_FILES = \
> OS2_BRANDING_FILES = \
> 	firefox-os2.ico \
> 	document-os2.ico \
> 	$(NULL)
> 
> export::
> 	$(NSINSTALL) -D $(DIST)/branding
> ifeq ($(MOZ_WIDGET_TOOLKIT),windows)
>+	$(PYTHON) $(topsrcdir)/config/Preprocessor.py -Fsubstitution $(DEFINES) $(ACDEFINES) $(srcdir)/branding.nsi > $(DIST)/branding/branding.nsi
Why didn't you just add the values to DEFINES and set the values in defines.nsi.in. There is also a BrandShortName in that file.

I suspect there might be a couple of places where the logic will need to change as well but the above should get things most of the way there.

Comment 6

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

> Why didn't you just add the values to DEFINES and set the values in
> defines.nsi.in. There is also a BrandShortName in that file.

Does that mean I can just remove the !BrandShortName define in branding.nsi? I.e. are we currently depending on it overriding the one in defines.nsi?

Comment 7

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

!define BrandShortName only exists in defines.nsi.in
http://mxr.mozilla.org/mozilla-central/search?string=!define+BrandShortName

What I think you are asking is what to do about BrandFullNameInternal. Since the suffix number is being removed I *think* it can just use BrandFullName for now. I am also somewhat concerned about changing the shortcut names since users will end up with an additional set of shortcuts in some cases.

Comment 8

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

Oops yes, confused the two. I don't know which is used for what, so all I was basing that change on was the fact that we typically always update BrandFullNameInternal when rebranding.

Comment 9

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

btw: bug 628869 and Bug 628868 were created in support of a product marketing initiative to standardize on Mozilla Firefox for releases and it is my understanding that we are now moving to just Firefox for releases (at least for shortcut names and app bundles). Before the change is made to Firefox for release that bug should be wontfix'd so we don't have to create migration code to go from the current shortcut name of "Mozilla Firefox" to "Firefox" (the current decision) and then back to "Mozilla Firefox"

Comment 10

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

Looks like product marketing no longer wants to go with "Mozilla Firefox" and both bug 628869 and Bug 628868 should be wontfix so they are no longer blocking this.

Since I sank a ton of time into this release already please ask Jim Mathies for review since he is an Firefox -> Installer peer. That way I can hopefully focus on other work I need to get done / keep getting asked about.

The only concerns I have with this approach are with the Windows shortcut naming (e.g. do existing shortcuts get migrated or not) and that the three repositories are properly unique in the registry.

Comment 11

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

Is the feedback request from me still relevant?

Comment 12

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

Yes, for the configure/autoconf changes.

Comment 13

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

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

Glancing at the patch, your MOZ_APP_DISPLAYNAME_[PRE|SUF]FIX makefile variables are wrong.  Since you're only conditionally AC_SUBST()ing if --with-displayname-prefix is not used MOZ_APP_DISPLAYNAME_PREFIX is going to be set to @MOZ_APP_DISPLAYNAME_PREFIX@ in makefiles.

It doesn't look like you actually use those in makefiles though ... so you can just revert the autoconf.mk.in changes and remove both AC_SUBST()s.

Comment 14

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

Looks like we're not going to end up doing this.

Comment 15

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

I think it turns out that we're going to do something similar in bug 696436.