Closed Bug 1413295 Opened 7 years ago Closed 7 years ago

Rename "Mozilla Firefox" to "Firefox" on Windows

Categories

(Firefox :: Installer, defect, P1)

Product:
Firefox
Component:
Installer
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 58
Tracking Flags:
Tracking Status
firefox57 blocking fixed
firefox58 --- verified

People

(Reporter: ddurst, Assigned: molly)

References

Details

(Whiteboard: [fce-active-legacy])

Attachments

(1 file, 2 obsolete files)

bug1413295.diff
27.82 KB, patch
robert.strong.bugs
: review+
ritu
: approval-mozilla-beta+
Details | Diff | Splinter Review 
We want to change the shortcut label from its current value ("Mozilla Firefox") to the shorter "Firefox".

This includes two parts:

1) applying to new installs (starting with 57), and
2) applying to updates (starting with TBD)

Let's use this bug to also identify risks.

For Windows:
a) start menu (and pinned tiles)
b) desktop shortcuts
Known risks:

# Applying to updates

* Windows users that don't perform the update won't have their shortcuts (desktop, start menu, and pinned) renamed since the file system security won't allow the user that performed the update to access the other user's profile on the file system.

* The shortcut location will display in a different location on the desktop and the start menu due to sorting (which will create confusion for some users when they try to find the shortcut to launch Firefox)[1].

* Renaming a pinned taskbar item makes it... disappear completely.


[1] from rstrong: If I recall correctly, this is the reason this was not done in the Firefox single digit days and UX made the call back then.
Attached patch Patch - new installs and updates (obsolete) — — Splinter Review 
This patch both creates shortcuts with the new names for new installs and also renames existing shortcuts on updates (if the installer created them).

The changes made here fall into two categories:
1) Search-and-replace $BrandFullName with $BrandShortName in code involved in creating shortcuts. This is most of the lines changed.
2) Fix the bug 1354321 patch, which is needed for updating existing shortcuts. That patch didn't properly set the shell context the new code ran under, so it would only touch shortcuts in the per-user locations.
To clarify some points about the above known risks:

(In reply to David Durst [:ddurst] from comment #1)
> * Windows users that don't perform the update won't have their shortcuts
> (desktop, start menu, and pinned) renamed since the file system security
> won't allow the user that performed the update to access the other user's
> profile on the file system.

This will be a problem only when a machine has multiple user accounts which all use the same copy of Firefox (a pretty uncommon configuration), and which have their shortcuts to that copy of Firefox in per-user locations instead of the per-machine locations (an even less common configuration). In that case, we will only be able to rename the shortcuts of the user account which performed the installation.

> * The shortcut location will display in a different location on the desktop
> and the start menu due to sorting (which will create confusion for some
> users when they try to find the shortcut to launch Firefox)[1].

The entry in the start menu all programs list is what will move, but any tiles pinned to the start menu will not move. Desktop icons may or may not get moved based on the layout of the desktop, but we have no control over that, so we should assume they will move.
Attached patch Patch - new installs and updates (obsolete) — — Splinter Review 
Minor revision - move back a block of code that I had incorrectly moved to get it above another call, and just move that call instead.
Attachment #8923950 - Attachment is obsolete: true
Comment on attachment 8924019 [details] [diff] [review]
Patch - new installs and updates

As discussed on IRC, I don't expect this review to come back today because :rstrong is already in the middle of one.
Attachment #8924019 - Flags: review?(robert.strong.bugs)
Hi Tom, Andrei, this is a late change we are being asked to uplift to Beta57. This is changing the shortcut and start menu from "Mozilla Firefox" to "Firefox". Hopefully these patches will be in 57.0b14 and we'd appreciate some focused testing around this. Thanks!
Flags: needinfo?(tgrabowski)
Flags: needinfo?(andrei.vaida)
Here's what needs to be verified with this patch:

* All shortcuts created for a new installation use the short name (e.g. "Firefox") instead of the long name (e.g. "Mozilla Firefox"). This includes desktop, start menu, and, for Win7 and 8, taskbar (on Windows 10 the installer does not create a taskbar shortcut).
* On updating to a build with this patch, desktop and start menu shortcuts that were created by the installer are renamed to use the short name, whether the installer was run from an account with administrator privileges or not.
* On updating to a build with this patch, shortcuts to other installations that were not updated are not renamed.
* On updating to a build with this patch, shortcuts that do not have the same name as those created by the installer are not renamed.


This should all be checked on Windows 7, 8, and 10. No other OS's are affected, and there's no specific 32-bit vs. 64-bit concerns here, so there's no need to perform all the testing on both architectures.

Somewhat unusually for patches that affect app update, for this patch it doesn't matter what build is being updated *from*; all that matters is that the build being updated *to* has this patch.

As explained above, taskbar pinned shortcuts not being renamed, desktop icons moving when being renamed, and shortcuts owned by other users not being renamed are all known and expected issues.
Maybe we want also to double check that
* anti-virus software don't check this information
* some extensions relying on that (like bug 1404956)
(In reply to Sylvestre Ledru [:sylvestre] from comment #9)
> Maybe we want also to double check that
> * anti-virus software don't check this information
> * some extensions relying on that (like bug 1404956)

I think this is very very unlikely to be an issue. It's very difficult to find out anything about the shortcut that a Windows application was launched from (even for the application itself, let alone for third-party code). An antivirus could probably do something invasive enough to let it get that information, but then there's not much it could do with that.
Thanks. I became paranoid with this kind of changes as AV can be a nit-picky!
ok - UX TL;DR: No strong concerns about risk to users here.

More details:

- Really no concerns for _new_ users.

- In some places, familiar icon position will change (i.e. alphabetical list in the Widows/Start menu), but will not in the places that we think people go to most (desktop shortcut; icon in the frequently used section at the top of that menu; taskbar icon if we're not messing with that as in Comment 8). In that alphabetical list, Firefox will now be higher in the list and will continue to have a very familiar and noticeable icon. Some people will almost certainly wonder where it's gone, but I don't think I can argue it will cause a serious findability/launchability problem.

- We do know from user research that there are users who do refer to Firefox as "Mozilla Firefox" or even "Mozilla." We don't have this in a quantified way. There's some sense from recent onboarding research that this may more represent a cohort of returning users from Firefox's early days. Strategy and Insights team may have more data on these numbers from how they talk about the product in their surveys (need-infoing Matt Grimes); but regardless, from a findability perspective, I'm not sure these numbers dominate the argument about primary locations in the previous point.

- Including the name Mozilla does seem, for some users, to reinforce brand message we bring in that way - around trust, etc. Arguably, there are other places to infuse that than in the shortcut icon label.

- For positives -- going with the Firefox name better connects to the steps in the user flow around this: Firefox branding on the websites; the Firefox name in the onboarding tour; the renamed "Firefox Installer."
Flags: needinfo?(mgrimes)
Thanks, Madhava. One correction:

(In reply to Madhava Enros [:madhava] from comment #12)
> - In some places, familiar icon position will change (i.e. alphabetical list
> in the Widows/Start menu), but will not in the places that we think people
> go to most (desktop shortcut; icon in the frequently used section at the top
> of that menu; taskbar icon if we're not messing with that as in Comment 8).

It doesn't always happen, but the position of the desktop shortcut *can* change during this rename. Does that affect your conclusions?
Flags: needinfo?(madhava)
Flags: needinfo?(mgrimes)
(In reply to Madhava Enros [:madhava] from comment #12)

> - We do know from user research that there are users who do refer to Firefox
> as "Mozilla Firefox" or even "Mozilla." We don't have this in a quantified
> way. There's some sense from recent onboarding research that this may more
> represent a cohort of returning users from Firefox's early days. Strategy
> and Insights team may have more data on these numbers from how they talk
> about the product in their surveys (need-infoing Matt Grimes); but
> regardless, from a findability perspective, I'm not sure these numbers
> dominate the argument about primary locations in the previous point.

We don't have those numbers off hand, but it would be fairly straight forward to get that from Heartbeat. My question would be if the data would change the decision here. If you think it might, we can get that shipped soon. Adding Tyler for visibility.
I don't think so, in the grand scheme of things -- if we think our icon is still visible on screen.

But to make sure we've bounded that case - what do we know about when it happens? My (probably incomplete) understanding here is that in Win10, tiles are manually place. For desktop shortcut icons, they _can_ be arranged alphabetically, but that that's not the default.
(In reply to Matt Grimes [:Matt_G] from comment #14)
> (In reply to Madhava Enros [:madhava] from comment #12)
> 
> We don't have those numbers off hand, but it would be fairly straight
> forward to get that from Heartbeat. My question would be if the data would
> change the decision here. If you think it might, we can get that shipped
> soon. Adding Tyler for visibility.

No - it was mostly to see if we knew anything surprising already, given the timeline.
Flags: needinfo?(madhava)
(In reply to Madhava Enros [:madhava] from comment #15)
> I don't think so, in the grand scheme of things -- if we think our icon is
> still visible on screen.
> 
> But to make sure we've bounded that case - what do we know about when it
> happens? My (probably incomplete) understanding here is that in Win10, tiles
> are manually place. For desktop shortcut icons, they _can_ be arranged
> alphabetically, but that that's not the default.

You're right, but it is also possible for a non-sorted icon to get moved. This does seem less likely than I expected, I've only seen it happen once in my testing for this patch, but it depends on the timing of how the desktop gets refreshed so it can't be ruled out.
It seems like there's a lot of unknowns about all of this and we're literally days away from our first RC build. What's driving this decision *now*?
We have run some studies recently that well over 97% of users are able to correctly identify Firefox based on the logo alone. I doubt that removing the word Mozilla will change that significantly. 

The organization issue is a bigger worry, but I'm not sure we can test that in HB.
Hi Tom, Andrei, I'd urge QA, Dev, UX to come up with a solid test plan for this that covers the right matrix of scenarios for this change. That will ensure we find those nasty bugs before this goes out.
Hi Matt, do you believe the fix will be ready by EOD today/early am PST tomm? The sooner this can hit beta the better. Tomm is the last beta (b14) gtb. If this misses tomm am landing in m-b, it will hit beta in the first RC build on Tuesday leaving us with a week of beta audience feedback on it.
Flags: needinfo?(mhowell)
I do expect to have this ready by EOD today, yes.
Flags: needinfo?(mhowell)
Comment on attachment 8924019 [details] [diff] [review]
Patch - new installs and updates

>diff --git a/browser/installer/windows/nsis/shared.nsh b/browser/installer/windows/nsis/shared.nsh
>--- a/browser/installer/windows/nsis/shared.nsh
>+++ b/browser/installer/windows/nsis/shared.nsh
>@@ -32,69 +32,66 @@
>   SetShellVarContext current  ; Set SHCTX to the current user (e.g. HKCU)
>   ${RegCleanMain} "Software\Mozilla"
>   ${RegCleanUninstall}
>   ${UpdateProtocolHandlers}
> 
>   ; setup the application model id registration value
>   ${InitHashAppModelId} "$INSTDIR" "Software\Mozilla\${AppName}\TaskBarIDs"
> 
>-  ; Win7 taskbar and start menu link maintenance
>-  Call FixShortcutAppModelIDs
>-
>   ClearErrors
>   WriteRegStr HKLM "Software\Mozilla" "${BrandShortName}InstallerTest" "Write Test"
>   ${If} ${Errors}
>     StrCpy $TmpVal "HKCU"
>   ${Else}
>     SetShellVarContext all    ; Set SHCTX to all users (e.g. HKLM)
>     DeleteRegValue HKLM "Software\Mozilla" "${BrandShortName}InstallerTest"
>     StrCpy $TmpVal "HKLM"
>     ${RegCleanMain} "Software\Mozilla"
>     ${RegCleanUninstall}
>     ${UpdateProtocolHandlers}
>     ${FixShellIconHandler} "HKLM"
>     ${SetAppLSPCategories} ${LSP_CATEGORIES}
> 
>-    ; Win7 taskbar and start menu link maintenance
>-    Call FixShortcutAppModelIDs
>-
>     ; Add the Firewall entries after an update
>     Call AddFirewallEntries
> 
>     ReadRegStr $0 HKLM "Software\mozilla.org\Mozilla" "CurrentVersion"
>     ${If} "$0" != "${GREVersion}"
>       WriteRegStr HKLM "Software\mozilla.org\Mozilla" "CurrentVersion" "${GREVersion}"
>     ${EndIf}
>   ${EndIf}
> 
>   ; Migrate the application's Start Menu directory to a single shortcut in the
>   ; root of the Start Menu Programs directory.
>   ${MigrateStartMenuShortcut}
> 
>-  ; Update lastwritetime of the Start Menu shortcut to clear the tile cache.
>+  ; Adds a pinned Task Bar shortcut (see MigrateTaskBarShortcut for details).
>+  ${MigrateTaskBarShortcut}
>+
>+  ; Update the name/icon/AppModelID of our shortcuts as needed, then update the
>+  ; lastwritetime of the Start Menu shortcut to clear the tile icon cache.
>   ; Do this for both shell contexts in case the user has shortcuts in multiple
>   ; locations, then restore the previous context at the end.
>   ${If} ${AtLeastWin8}
>     SetShellVarContext all
>+    ${UpdateShortcutBranding}
UpdateShortcutBranding is no longer called on Win 7 with this change

>     ${TouchStartMenuShortcut}
>+    Call FixShortcutAppModelIDs
>     SetShellVarContext current
>+    ${UpdateShortcutBranding}
UpdateShortcutBranding is no longer called on Win 7 with this change

>     ${TouchStartMenuShortcut}
>+    Call FixShortcutAppModelIDs
>     ${If} $TmpVal == "HKLM"
>       SetShellVarContext all
>     ${ElseIf} $TmpVal == "HKCU"
>       SetShellVarContext current
>     ${EndIf}
>   ${EndIf}
> 
>-  ; Adds a pinned Task Bar shortcut (see MigrateTaskBarShortcut for details).
>-  ${MigrateTaskBarShortcut}
>-
>-  ${UpdateShortcutBranding}
>-
>   ${RemoveDeprecatedKeys}
>   ${Set32to64DidMigrateReg}
> 
>   ${SetAppKeys}
>   ${FixClassKeys}
>   ${SetUninstallKeys}
>   ${If} $TmpVal == "HKLM"
>     ${SetStartMenuInternet} HKLM

In the uninstaller you might want to continue to check for the existance of the old shortcut name that points to the install location and remove it if it exists.
Attachment #8924019 - Flags: review?(robert.strong.bugs) → review-
Attached patch bug1413295.diff — — Splinter Review 
Fixed the above review findings and also a typo in the comments on UpdateShortcutBranding.
Attachment #8924019 - Attachment is obsolete: true
Attachment #8924245 - Flags: review?(robert.strong.bugs)
Comment on attachment 8924245 [details] [diff] [review]
bug1413295.diff

Looks good.

I think that MigrateStartMenuShortcut can be removed now but that should be done in a new bug since it doesn't need to be uplifted.
Attachment #8924245 - Flags: review?(robert.strong.bugs) → review+
During 55, we have learned how difficult it is to test all possible configurations our users can have in their OS related to seemingly simple things like folder names. Check https://bugzilla.mozilla.org/show_bug.cgi?id=1388584 as an example.  The result of our post-mortem at that time was that we need more time to test changes like this.

This is a change that can potentially derail 57 if users cannot start Firefox when clicking on the shortcut, or the shortcut disappears or moves in an unexpected place. Moreover, from the comments above, it is not clear that this change is 100% recommended from UX perspective.

My recommendation as QA is to postpone this change to 58. This will give us enough time to properly test it and assure that users won't have negative experience after updating Firefox. The reason we have post-mortems is exactly so that we can make informed decisions in situations like this one here.
Flags: needinfo?(tgrabowski)
https://hg.mozilla.org/integration/mozilla-inbound/rev/b910a12076247284644a00029522a9743219eeff
Bug 1413295 - Use BrandShortName as the title for new shortcuts, and rename existing shortcuts our installer created. r=rstrong
https://hg.mozilla.org/mozilla-central/rev/b910a1207624
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox58: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 58
Hi Matt, David, is this ready for uplift to Beta? I will gtb in an hour and was hoping to include this patch.
Flags: needinfo?(mhowell)
Flags: needinfo?(ddurst)
Comment on attachment 8924245 [details] [diff] [review]
bug1413295.diff

Approval Request Comment
[Feature/Bug causing the regression]:
N/A

[User impact if declined]:
I'll quote an e-mail from Dave Camp here:
"We've put a ton of work into nailing the first impression of Firefox 57.  It's hard to get more first-impression than the desktop icon, and the word-wrapping your title on the desktop and pushing the product name we're placing first everywhere else gives a cruddy first impression."

[Is this code covered by automated tests?]:
No

[Has the fix been verified in Nightly?]:
Unfortunately this can't really be tested on Nightly, because that's the one channel where the full name and the short name are the same (both are just "Nightly"), so the patch doesn't change anything.

[Needs manual test from QE? If yes, steps to reproduce]: 
Yes, testing plans are being worked out.

[List of other uplifts needed for the feature/fix]:
None

[Is the change risky?]:
Moderately

[Why is the change risky/not risky?]:
The risk in my opinion is just the fact that new behavior is being introduced into the app update path. I don't think that behavior itself is particularly risky, and it's difficult to see where serious problems could come from, but anything being done in that process does merit scrutiny.

[String changes made/needed]:
None, reusing existing strings
Attachment #8924245 - Flags: approval-mozilla-beta?
Good timing, Ritu. ;)
Flags: needinfo?(mhowell)
Comment on attachment 8924245 [details] [diff] [review]
bug1413295.diff

Must fix, (fingers crossed) this late change will go smoothly, beta57+
Attachment #8924245 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: needinfo?(ddurst)
Blocks: 1415089
Flags: needinfo?(andrei.vaida)
Flags: qe-verify+
I verified this issue using Latest Firefox Beta with Build ID 20171123161455 on Windows 7 x64 and Windows 10 x64.
I will mark this as verified fixed.
Status: RESOLVED → VERIFIED
status-firefox58: fixed → verified
Flags: qe-verify+
Whiteboard: [fce-active] → [fce-active-legacy]
So, here is a question on this.  Is there a way for us to stop the installer from doing this rename?  We have a Mozilla Firefox shortcut on the desktops of our images and we prestage the icon positions via the registry, so if you change the name of a shortcut, it messes up that prestaging of icon positions.  Sure, I can rename it via script, but if the user is signed in when the rename happens, it will cause the icons to shift. For the Start Menu, luckily, we had already copied the old Firefox shortcut to a Mozilla Firefox folder, so that isn't impacted.  I wish I had seen this while the change was being made so I could have submitted this feedback rather than trying to fix this after the fact.  I can submit a new ticket if that's the best way to handle this feedback.
No, there's no way to disable the rename procedure, that would be a new feature we would have to add (which means that, yes, submitting a new bug would be needed, thank you). Just to warn you though, we did discuss the possibility of icons shifting position when this change was implemented, because it's possible for that to happen even if nothing is managing the desktop layout, and the decision was that having that happen was an acceptable caveat, so I'm afraid the priority on getting that work done would not be very high.
Alright, well I figured out a work-around.  All I'm doing is echo.> "%public%\desktop\Firefox.lnk" at the start of my batch install to create a temp shortcut with the name the installer is looking for, then at the end, I just issue a delete of that temp shortcut.
My Start Menu layouts would have been messed up too, but a long time ago, I kept the Start Menu folder called Mozilla Firefox and that is what the XML references, so the new shortcuts that now live at the root don't interfere.  Otherwise, I would have to rebuild my XML layout files for the Start Menu too and that would not be fun.

Sorry to be the guy who makes the images not follow the new naming standard, but I really don't feel like capturing new Desktop layouts and then injecting them into each user profile.  I use a script to generate icon positions for all common resolutions and it must somehow reference the shortcut names.  I just figured I would share this to show that even though a seemingly innocent change was made, it had potentially detrimental consequences in our environment.  Luckily, the work around is pretty easy.  I at first was over-thinking that I could block with permissions, but permissions won't prevent a rename apparently.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: