Closed Bug 1621024 Opened 1 year ago Closed 1 year ago

Skip reporting errors if the file is not found in the L10nRegistry.loadSync

Categories

(Core :: Internationalization, defect, P2)

Desktop
All
defect

Tracking

()

RESOLVED FIXED
mozilla76
Tracking Status
firefox-esr68 --- unaffected
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- fixed

People

(Reporter: jimm, Assigned: zbraniecki)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

The payment request dialog currently fails to show on Windows due to a fluent related issue. The failure occurs in the form auto fill initialization here -

https://searchfox.org/mozilla-central/source/browser/extensions/formautofill/FormAutofill.jsm#129

stack:
[JavaScript Error: "[Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIChannel.open]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: L10nRegistry.loadSync :: line 774" data: no]"]
L10nRegistry.loadSync@resource://gre/modules/L10nRegistry.jsm:774:12
fetchFile@resource://gre/modules/L10nRegistry.jsm:676:31
generateResourceSetSync/<@resource://gre/modules/L10nRegistry.jsm:581:19
generateResourceSetSync@resource://gre/modules/L10nRegistry.jsm:576:22
generateResourceSetsForLocaleSync@resource://gre/modules/L10nRegistry.jsm:412:44
generateBundlesSync@resource://gre/modules/L10nRegistry.jsm:174:7
touchNext@resource://gre/modules/Localization.jsm:167:37
onChange@resource://gre/modules/Localization.jsm:500:20
Localization@resource://gre/modules/Localization.jsm:227:10
getRegionDisplayNames@resource://gre/modules/mozIntl.jsm:736:19
@resource://formautofill/FormAutofill.jsm:129:36
get@resource://gre/modules/XPCOMUtils.jsm:129:51
exposeUtilityFunctions@chrome://payments/content/paymentDialogFrameScript.js:96:7
sendToChrome@chrome://payments/content/paymentDialogFrameScript.js:158:12
handleEvent@chrome://payments/content/paymentDialogFrameScript.js:64:10
sendMessageToChrome@resource://payments/paymentRequest.js:76:14
init@resource://payments/paymentRequest.js:28:10
@resource://payments/paymentRequest.js:354:16

The path to the resource is -
resource://gre/localization/en-US/toolkit/intl/regionNames.ftl

Odd because I can open this in both nightly and my local build.

Understanding regression range would be helpful here.

This error indicates that some file cannot be fetched synchronously from MozIntl, called in the chrome process.
My first guess is that maybe the call is fired too early?

Jim, can you provide STR?

And if you can instrument https://searchfox.org/mozilla-central/source/intl/l10n/L10nRegistry.jsm#758 to add console.log(uri) then we could learn what URI is failing.

As a side note, I'd like to understand why this exception fails to be caught by the try/catch it's in. This seems like a JS engine bug

Oh, thank you, yeah. Ok, so nothing unusual in the fetch, mozIntl requires it.

Is the payment request dialog fired early in the startup or during app's life cycle?

If it's during life-cycle, can you open browser console and call Services.intl.getLocaleDisplayNames(undefined, ["pt-DE"]); before launching the payments dialog?

This should fetch the same file via the same MozIntl.

Flags: needinfo?(jmathies)

Looks like it may have come through this loadSync call twice, failing on the first, succeeding on the second call. I'll keep poking at it.

Flags: needinfo?(jmathies)
No longer depends on: 1616863
Priority: P1 → P3
Attached image wierd outline.png

I actually seeing what appears to be a dialog outline painted in chrome. Really odd, it looks like something is displaying but it's broken.

Right, that's bug 1616863

Looks like it may have come through this loadSync call twice, failing on the first, succeeding on the second call. I'll keep poking at it.

Does it mean that the locale shows up, just with an error in the console?

The logic makes sense - we first try to load the file from browser's omni.ja, and only then from toolkit's omni.ja.
The only question is why the exception is not being caught by the try/catch then.

The only question is why the exception is not being caught by the try/catch then.

Sorry for the drive-by comment, but I was curious—are you sure it's not being caught? Logging Cu.reportError(Components.Exception('Oops!', Cr.NS_ERROR_UNEXPECTED)) in the browser console produces something similar to that, stack trace and all. I wonder, could it be we're actually catching it, and it's just the formatting from the Cu.reportError call suggesting it's not being caught?

Yep, that seems it.

I guess since sync loading there is fallible, we should just not report the error if the file is missing, since it is an expected scenario.

I'll provide a patch.

Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Component: WebPayments UI → Internationalization
Product: Firefox → Core

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

Priority: P3 → --

This bug does not have steps to reproduce so a regression range could not be attempted, let alone provide it, but the bug's description shows the code where the request fails and it appears that the bug is already being addressed. This being said, I will remove the "regressionwindow-wanted" tag.

Updating the title here to reflect the change. Pretty sure the dialog display issue is a dupe of bug 1616863.

Summary: Payment Request dialog fails to display on Windows → Skip reporting errors if the file is not found in the L10nRegistry.loadSync
Priority: -- → P2
Pushed by zbraniecki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f29caeedf51e
Skip reporting errors if the file is not found in the L10nRegistry.loadSync. r=mossop
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
Duplicate of this bug: 1557713

The patch landed in nightly and beta is affected.
:zbraniecki, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(gandalf)

I don't think we want to uplift.

Flags: needinfo?(gandalf)
You need to log in before you can comment on or make changes to this bug.