1790809 - two private browsing shortcuts are sometimes created

Status: VERIFIED FIXED

(Firefox :: Shell Integration, defect, P1)

Description

[[e-mail] (:bhearsum)]

QA reported this in https://bugzilla.mozilla.org/show_bug.cgi?id=1789991#c10, but it's actually a distinct issue. The problem boils down to the fact that we have two separate strings for the Private Browsing shortcuts (one for the installer, one for the browser), and if they don't match, we'll end up with two shortcuts. This can happen in at least two cases:

1. If a localized build has only translated one string -- in which we end up with a localized shortcut and an en-US one (ew)
2. If a localized build has translated the two strings differently - we end up with two slightly different localized shortcuts.

As far as I know, there's no way to share strings between the installer and the browser, so I think the best fix here is to simply remove shortcut creation from the installer (which was only added as an optimization). Doing so will cause a small amount of I/O at first run, but that's on a background thread these days anyways. Once the shortcut is created successfully once all of that I/O is skipped in subsequent launches.

The other downside to not doing it in the installer is that the shortcut will not exist until Firefox runs - but given that our primary install flow (the stub installer) automatically launches Firefox, this seems OK enough.

Comment 1

[[e-mail] (:bhearsum)]

Attachment: Bug 1790809: stop creating private browsing shortcuts in the installer r?bytesized!

It's important that this shortcut exists to avoid https://bugzilla.mozilla.org/show_bug.cgi?id=1762994. We were creating it in the installer to avoid first run I/O, with a fallback at runtime to catch zip builds and updates. Due to some of this code being in the installer and some of it in the browser, we ended up with two different strings. Unfortunately, this has resulted in a bug where we sometimes create two private shortcuts. This happens in at least two cases:

1. A localization has only translated one of those strings -- in which case we get an en-US string and a localized string
2. A localization has translated the strings differently -- in which case we get two localized, but slightly different, stings

Since the installer creation of the shortcut is an optimization, and the first run I/O is now on a background thread anyways, let's just get rid of the installer shortcut rather than trying to come up with a more complex fix for this.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b2b72ce4b4ff
stop creating private browsing shortcuts in the installer r=bytesized

Comment 3

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/b2b72ce4b4ff

Comment 4

[Monica Chiorean]

(In reply to [e-mail] (:bhearsum) from comment #1)

Created attachment 9294689 [details]
Bug 1790809: stop creating private browsing shortcuts in the installer r?bytesized!

It's important that this shortcut exists to avoid https://bugzilla.mozilla.org/show_bug.cgi?id=1762994. We were creating it in the installer to avoid first run I/O, with a fallback at runtime to catch zip builds and updates. Due to some of this code being in the installer and some of it in the browser, we ended up with two different strings. Unfortunately, this has resulted in a bug where we sometimes create two private shortcuts. This happens in at least two cases:

1. A localization has only translated one of those strings -- in which case we get an en-US string and a localized string
2. A localization has translated the strings differently -- in which case we get two localized, but slightly different, stings

Since the installer creation of the shortcut is an optimization, and the first run I/O is now on a background thread anyways, let's just get rid of the installer shortcut rather than trying to come up with a more complex fix for this.

Do you know the exact languages that use different localizations like 1 an 2 mentioned above, so we can check both scenarios? Thank you.

Comment 5

[[e-mail] (:bhearsum)]

(In reply to Monica Chiorean from comment #4)

(In reply to [e-mail] (:bhearsum) from comment #1)

Created attachment 9294689 [details]
Bug 1790809: stop creating private browsing shortcuts in the installer r?bytesized!

It's important that this shortcut exists to avoid https://bugzilla.mozilla.org/show_bug.cgi?id=1762994. We were creating it in the installer to avoid first run I/O, with a fallback at runtime to catch zip builds and updates. Due to some of this code being in the installer and some of it in the browser, we ended up with two different strings. Unfortunately, this has resulted in a bug where we sometimes create two private shortcuts. This happens in at least two cases:

1. A localization has only translated one of those strings -- in which case we get an en-US string and a localized string
2. A localization has translated the strings differently -- in which case we get two localized, but slightly different, stings

Since the installer creation of the shortcut is an optimization, and the first run I/O is now on a background thread anyways, let's just get rid of the installer shortcut rather than trying to come up with a more complex fix for this.

Do you know the exact languages that use different localizations like 1 an 2 mentioned above, so we can check both scenarios? Thank you.

I can't give you a complete list, but fr and es-ES are on the list given https://bugzilla.mozilla.org/show_bug.cgi?id=1789991#c10.

Of note though - if my patch is correct there is only ever one place (and one string) for shortcuts now. So as long as the installer is not creating a Private shortcut, it should be impossible to have second or mismatched ones.

Comment 6

[Monica Chiorean]

Could not reproduce the issue using latest Beta 106.0b8(20221004185850). I used ES and FR localizations.