1940763 - Crash Reporter window fails to open after a crash in some localized builds

Status: VERIFIED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Simona Badau, Desktop QA]

Found in

• Firefox 135.0b2

Affected versions

• Nightly 136.0a1
• Firefox 135.0b2
• Firefox 134
• Firefox 128.6.0esr

Tested platforms

• Affected platforms: macOS 15, Windows 11, Ubuntu 22.04

Preconditions

• Ensure a localized build is installed (e.g., Romanian "ro" build).

Steps to reproduce

1. Navigare to "about:crashparent".
2. Observe the Firefox Crash Reporter window and choose to Restart Firefox.

Expected result

• The Crash Reporter window should open after a Firefox crash.

Actual result

• The Firefox Crash Reporter window does not open at all, and the user needs to manually relaunch Firefox. The crash appears in about:crashes under the "Unsubmitted Crash Reports" list.

Regression range

• The regression was introduced somewhere between Firefox 126 and Firefox 127. I will provide a more accurate regression range as soon as possible.

Additional notes

• This behavior is not limited to "ro" builds; it also occurs with "ar" builds.
• The Firefox Crash Reporter window is displayed correctly in "fr" builds and certain others (e.g., "it" build).

Comment 1

[Alex Franchuk [:afranchuk]]

This is due to the localization file missing string identifiers. Whoever is responsible for localizing the fluent files for these languages has not updated them in newer versions as new identifiers have been added.

However, the installer does have multiple locales set up (e.g. en-US is in there), and the en-US does have all the strings. We should load all locales in the omnijar and fall back when a string is missing from one (and the crash reporter embeds en-US itself, which is almost guaranteed to work as that's what's used during development, so that can be a final fallback).

:gsvelto, does this sound good? We definitely don't want to crash here when we do have the capability to use some string (it just won't be localized).

Comment 2

[Alex Franchuk [:afranchuk]]

Attachment: Bug 1940763 - Load all available locales in the crash reporter client r=gsvelto

This includes the embedded en-US locale. This way, no matter what
happens, we will only crash due to localization if we have a logic error
like not adding a localization string id to the fluent file.

Comment 3

[Gabriele Svelto [:gsvelto]]

Yes, that sounds like the best approach if it's feasible.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d5a3c6241fb3
Load all available locales in the crash reporter client r=gsvelto

Comment 5

[Serban Stanca [:SerbanS]]

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

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:afranchuk, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox135 to wontfix.

For more information, please visit BugBot documentation.

Comment 7

[Alex Franchuk [:afranchuk]]

Attachment: Bug 1940763 - Load all available locales in the crash reporter client

This includes the embedded en-US locale. This way, no matter what
happens, we will only crash due to localization if we have a logic error
like not adding a localization string id to the fluent file.

Original Revision: https://phabricator.services.mozilla.com/D233760

Comment 8

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Some users will not be presented with the crash reporter client when the main process crashes.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Install firefox with a bundled locale that has not been kept up-to-date (for instance, the Romanian installer). Navigate to about:crashparent and verify that the crash reporter client comes up.
• Risk associated with taking this patch: Low
• Explanation of risk level: This results in at least the same locale behavior as previously done, and removes a bunch of error paths, replacing them with fallback logic to (at worst) show the bundled en-US locale.
• String changes made/needed: N/A
• Is Android affected?: no

Comment 9

[Alex Franchuk [:afranchuk]]

Does anyone want to weigh in about uplifting to release/esr? This will affect any bundled installer localizations which have not been kept up-to-date (the crashreporter.ftl file has not been localized). Is it easier to get those localizations updated rather than uplift? Also, the crash report is still saved so there is potentially a means of sending it through about:crashes. The user experience of firefox crashing without the crash reporter client coming up is suboptimal, of course, but it's not something that users are unaccustomed to with software in general.

Related: why wasn't the localization kept up-to-date? Do some of the languages rely on voluntary updates? Did I do something wrong (insofar as not flagging some change as requiring localization updates)? I was under the impression such flagging was done automatically (maybe based on files changing within a release), but that might have just been blind optimism?

Comment 10

[Ryan VanderMeulen [:RyanVM]]

All of our localization is handled by volunteers. Some locales are better resourced than others.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

And +1 to uplifting this to all affected branches.

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/05abdaa66367

Comment 13

[Alex Franchuk [:afranchuk]]

Attachment: Bug 1940763 - Load all available locales in the crash reporter client

This includes the embedded en-US locale. This way, no matter what
happens, we will only crash due to localization if we have a logic error
like not adding a localization string id to the fluent file.

Original Revision: https://phabricator.services.mozilla.com/D233760

Comment 14

[Simona Badau, Desktop QA]

Verified as fixed using the "ro" and "ar" builds of the latest Nightly 136.0a1 on macOS 15, Ubuntu 24.04, and Windows 11. The crash report window, partially translated, is triggered as expected during a crash.

Alex, based on Comment 1, my understanding is that a partially translated crash report window is the expected behavior in this scenario. Could you please confirm if this is indeed the case?

Comment 15

[Alex Franchuk [:afranchuk]]

Yes, a partially translated window is the expected outcome.

Comment 16

[Alex Franchuk [:afranchuk]]

Uplifting to ESR128 would be easiest done by also uplifting bug 1873210. Otherwise I can make changes to avoid doing that, but it will technically be new code, so I would not feel as comfortable as simply uplifting with the patch from the other bug.

Comment 17

[Phabricator Automation]

release Uplift Approval Request

• User impact if declined: Some users will not be presented with the crash reporter client when the main process crashes.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Install firefox with a bundled locale that has not been kept up-to-date (for instance, the Romanian installer). Navigate to about:crashparent and verify that the crash reporter client comes up.
• Risk associated with taking this patch: Low
• Explanation of risk level: This results in at least the same locale behavior as previously done, and removes a bunch of error paths, replacing them with fallback logic to (at worst) show the bundled en-US locale.
• String changes made/needed: N/A
• Is Android affected?: no

Comment 18

[Alex Franchuk [:afranchuk]]

Attachment: Bug 1940763 - Load all available locales in the crash reporter client

This includes the embedded en-US locale. This way, no matter what
happens, we will only crash due to localization if we have a logic error
like not adding a localization string id to the fluent file.

Original Revision: https://phabricator.services.mozilla.com/D233760

Comment 19

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Some users will not be presented with the crash reporter client when the main process crashes.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Install firefox with a bundled locale that has not been kept up-to-date (for instance, the Romanian installer). Navigate to about:crashparent and verify that the crash reporter client comes up.
• Risk associated with taking this patch: Low-Medium
• Explanation of risk level: Very minor adjustments had to be made to apply the patches to ESR, however they were almost entirely changed code that doesn't exist in ESR. Otherwise, the functionality results in at least the same functionality as before (as far as loading the primary locale goes), but removes some error paths.
• String changes made/needed: N/A
• Is Android affected?: no

Comment 20

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/615762c2e96c

Comment 21

[Simona Badau, Desktop QA]

Based on Comment 14 and Comment 15, setting the tracking flag firefox136: to verified.

Comment 22

[Alex Franchuk [:afranchuk]]

These are at least the affected localizations (found using transvision on a particular identifier):
ach, af, am, an, ar, ast, az, azz, bg, bn, bs, ca, cak, crh, et, fa, ff, ga-IE, gd, gl, gu-IN, hi-IN, hy-AM, kab, km, kn, lij, lo, lt, ltg, lv, mk, ml, mr, ms, my, ne-NP, ro, scn, sco, si, son, sr, ta, te, tl, trs, ur, uz, wo, xh, zam

Comment 23

[Simona Badau, Desktop QA]

Verified as fixed using the localized builds mentioned in Comment 22 (except for those unavailable in the archive for download, such as am, azz, crh, lo, ltg, ml, ne-NP, scn, wo, and zam) on Firefox 135.0b5 across macOS 15, Ubuntu 24.04, and Windows 11. The crash report window, partially translated, is triggered as expected during a crash.

Comment 24

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/564c4595b2e1

Comment 25

[Simona Badau, Desktop QA]

Verified as fixed using 134.0.2 localized builds on macOS 15, Ubuntu 24.04 and Windows 11 - the crash report window, partially translated, is triggered as expected during a crash. Testing was done using the en-US build and all the locales mentioned in Comment 22, except for those not available in the archive already listed in Comment 23.

Comment 26

[Simona Badau, Desktop QA]

Verified as fixed using Firefox 128.7.0 ESR on Ubuntu 24.10, macOS 15 and Windows 11. The crash report window, partially translated, is triggered as expected after a crash. Testing was done using the en-US build and all the locales mentioned in Comment 22, except for those not available in the archive and listed in Comment 23.