Skip reporting errors if the file is not found in the L10nRegistry.loadSync
Categories
(Core :: Internationalization, defect, P2)
Tracking
()
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
![]() |
Reporter | |
Comment 1•3 years ago
•
|
||
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.
Assignee | ||
Comment 2•3 years ago
|
||
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
Assignee | ||
Comment 3•3 years ago
|
||
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.
![]() |
Reporter | |
Comment 4•3 years ago
|
||
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.
![]() |
Reporter | |
Updated•3 years ago
|
![]() |
Reporter | |
Comment 5•3 years ago
|
||
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.
Comment 6•3 years ago
|
||
Right, that's bug 1616863
Assignee | ||
Comment 7•3 years ago
|
||
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.
Comment 8•3 years ago
|
||
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?
Assignee | ||
Comment 9•3 years ago
|
||
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.
Comment 10•3 years ago
|
||
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.
Assignee | ||
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
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.
![]() |
Reporter | |
Comment 13•3 years ago
|
||
Updating the title here to reflect the change. Pretty sure the dialog display issue is a dupe of bug 1616863.
Updated•3 years ago
|
Comment 14•3 years ago
|
||
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
Comment 15•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Updated•3 years ago
|
Comment 17•2 years ago
|
||
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.
Assignee | ||
Comment 18•2 years ago
|
||
I don't think we want to uplift.
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Description
•