two private browsing shortcuts are sometimes created
Categories
(Firefox :: Shell Integration, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox106 | --- | verified |
People
(Reporter: bhearsum, Assigned: bhearsum)
References
Details
(Whiteboard: [fidedi-pbm])
Attachments
(1 file)
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:
- If a localized build has only translated one string -- in which we end up with a localized shortcut and an en-US one (ew)
- 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.
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
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:
- A localization has only translated one of those strings -- in which case we get an en-US string and a localized string
- 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 3•3 years ago
|
||
bugherder |
Comment 4•3 years ago
|
||
(In reply to bhearsum@mozilla.com (: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:
- A localization has only translated one of those strings -- in which case we get an en-US string and a localized string
- 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.
Assignee | ||
Comment 5•3 years ago
|
||
(In reply to Monica Chiorean from comment #4)
(In reply to bhearsum@mozilla.com (: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:
- A localization has only translated one of those strings -- in which case we get an en-US string and a localized string
- 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.
Updated•3 years ago
|
Comment 6•3 years ago
|
||
Could not reproduce the issue using latest Beta 106.0b8(20221004185850). I used ES and FR localizations.
Description
•