STR:

1. Open Troubleshooting Information ( about:support )
2. Open Browser Console ( Ctrl+Shift+J )
   and see this warning:

[fluent] Missing translations in en-US: no_constant_buffer_offsetting. Localization.jsm:202:13

I can't find that ID on searchfox, but this would be a problem of the calling code.

It could be related,
that I have it in Troubleshooting Information ( about:support ) at "Graphics section" in "Workarounds"

NO_CONSTANT_BUFFER_OFFSETTING

Unsupported by driver

https://searchfox.org/mozilla-central/search?q=NO_CONSTANT_BUFFER_OFFSETTING
shows some things,
so I'm blocking bug #1379413, which added it.

I have reproduced this issue in Windows 7 with Nightly v69.0a1 (2019-06-12), but not in Beta v68.0b9 or Release v67.0.2.

I have run a mozregression test and found this:
"2019-06-12T18:03:28: DEBUG : Found commit message:
Bug 1509423 - Test/manifest updates to account for minor rendering differences between HarfBuzz and Core Text. r=jrmuizel

Differential Revision: https://phabricator.services.mozilla.com/D31095

2019-06-12T18:03:28: DEBUG : Did not find a branch, checking all integration branches
2019-06-12T18:03:28: INFO : The bisection is done.
2019-06-12T18:03:28: INFO : Stopped"

I have a slight feeling that this result may not be correct. If it seems unrelated, please NI me to try again.
Thank you.

I'm sorry, but bouncing this back and forth isn't working. I already said in comment 1 that this isn't a Localization problem.

Bodea, please find the right module for this.

Considering the regressor, I will set the component as (Core) Layout: Text and Fonts. If still incorrect, please try and give it a more appropriate component. Thanks.

:Virtual, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

I don't see how this can have anything to do with bug 1509423. It must be coming from something related to bug 1379413, though I don't know if it's supposed to be going through localization at all or not...?

Resetting regressionwindow-wanted, as I'm doubtful comment 3 can be correct.

Marking as P3 until we can determine regression window and figure out what's up

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=69cc7fba27dec865c30895f9e63e375afc7cf396&tochange=c68ba2c62949ea7bb210666a1e67466205a75603

Regressed by: bug 1507595

@ blinky - Thank you very much for finding specific regression range!

The component has been changed since the priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

So AIUI we hit this:

https://searchfox.org/mozilla-central/rev/e42e1a1be58abbd81efd8d78d6d0699979f43138/toolkit/content/aboutSupport.js#613-616

with fallback.name being "no_constant_buffer_offsetting" ? Bas, is that right?

Before, we would have just displayed this key literally. There are (at least) two ways to fix this:

1. avoid fluent localization of the fallback keys entirely, and just always display them literally in about:support
2. add fluent keys for all the possible values of fallback.name (and ensure that that continues to happen for potential new fallbacks that we add code for).

I don't have strong feelings about which is better, though I suspect (1) might be easiest?

Moved out of l10n again because it's not the framework's fault that graphics + about:support combined pass it poor information, and it's right to complain. If we ever hit this on infra it might fail tests, but we probably don't at the moment.

The warnings aren't user visible so we shouldn't bother fixing this on 67, though it will mean that the relevant table has no text in the 'key' column, which will make it harder to diagnose graphics fallback issues, so we should maybe try to fix for 68.

That's a good point about being able to diagnose graphics issues. Time is pretty tight to fix this in 68, but we could reasonably aim to fix it in 69. Sotaro, are you sure of the P3 priority?

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information

We should just do 1. What's the way to do that?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #16)

We should just do 1. What's the way to do that?

Added a patch. Note that I can't test this, but AIUI this should work based on the comments here.

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #14)

That's a good point about being able to diagnose graphics issues. Time is pretty tight to fix this in 68, but we could reasonably aim to fix it in 69. Sotaro, are you sure of the P3 priority?

Sorry, it was set by mistake.

https://hg.mozilla.org/mozilla-central/rev/1b2f0c6d97da

I'm confirming that bug is fixed, starting in Mozilla Firefox Nightly 69.0a1 (2019-06-21), so I'm marking this bug as VERIFIED.
Thank you very much! \o/

Is this something we should consider for Beta uplift?

Comment on attachment 9073082 [details]
Bug 1557846 - don't localize gfx fallback names in about:support, r?jrmuizel

Beta/Release Uplift Approval Request

• User impact if declined: missing diagnostic information in about:support
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): 1-line JS fix that's well-understood and verified fixed on nightly
• String changes made/needed: nope

Comment on attachment 9073082 [details]
Bug 1557846 - don't localize gfx fallback names in about:support, r?jrmuizel

simple fix for about:support i18n, approved for 68 rc1

https://hg.mozilla.org/releases/mozilla-release/rev/99e76a986112

https://hg.mozilla.org/releases/mozilla-esr68/rev/99e76a986112

I'm confirming that bug is fixed, also in Mozilla Firefox Nightly 68.0 branches.
Thank you very much! \o/