save to pocket button not visible even though pref is true
Categories
(Firefox :: Pocket, defect, P2)
Tracking
()
People
(Reporter: thecount, Assigned: thecount)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
The profile this is happening in is from Poland. On nightly.
It looks like an uncaught js error is causing the pocket button to not finishing or start instantiating.
The js error is localization related.
The main error that's causing the Pocker button to fail is NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.formatStringFromName] SaveToPocket.jsm:272
There are a few other l10n errors in the console that I thought might be related, and they are:
[fluent] Missing translations in en-GB: urlbar-default-placeholder, urlbar-permissions-granted, urlbar-remote-control-notification-anchor, urlbar-switch-to-tab, urlbar-extension, urlbar-placeholder, urlbar-go-button, urlbar-page-action-button, urlbar-pocket-button. Localization.jsm:202:13
and
No localization found for [webconsole.input.editor.onboarding.dismiss.label] l10n.js:130:13
The last one has a call stack which I have a screen shot for and I'll add as an attachment.
There is a bit there about en-GB in one of the errors. I think that's unrelated, but never know. We were changing some stuff in the profile when we started to debug, and one of those was to play around with the region/locale. That might be why it's reporting en-GB there.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
•
|
||
Could someone reproducing the issue run this from the Browser Console:
[...Object.entries(Services.locale)].filter(([,v]) => typeof v != "function").join("\n")
It should output something like…
"appLocaleAsBCP47,pl
appLocalesAsBCP47,pl,en-US
packagedLocales,pl,en-US
availableLocales,pl,en-US
lastFallbackLocale,en-US
requestedLocales,pl
langNegStrategyLookup,2
isAppLocaleRTL,false
requestedLocale,pl
defaultLocale,pl
appLocalesAsLangTags,pl,en-US
regionalPrefsLocales,pl,en-US
webExposedLocales,pl,en-US
appLocaleAsLangTag,pl
langNegStrategyFiltering,0
langNegStrategyMatching,1"
Comment 2•4 years ago
|
||
Hey, I'm the owner of the profile Scott opened this bug for. Here's what I get when I run the command:
"appLocaleAsBCP47,en-GB
packagedLocales,en-US
availableLocales,en-US,en-GB
appLocalesAsBCP47,en-GB,en-US
lastFallbackLocale,en-US
requestedLocales,en-GB,en-US
langNegStrategyLookup,2
isAppLocaleRTL,false
requestedLocale,en-GB
regionalPrefsLocales,en-GB,en-US,pl-PL
defaultLocale,en-US
appLocalesAsLangTags,en-GB,en-US
webExposedLocales,en-GB,en-US,pl-PL
appLocaleAsLangTag,en-GB
langNegStrategyFiltering,0
langNegStrategyMatching,1"
Comment 3•4 years ago
|
||
I can reproduce when installing the en-GB langpack https://addons.mozilla.org/firefox/addon/english-gb-language-pack/
And unpacking the xpi shows no readerView.savetopocket.label
in chrome/en-GB/locale/en-GB/global/aboutReader.properties
although the string id did exist before bug 1637498 although not sure if the id was supposed to be updated?
Comment 4•4 years ago
|
||
Probably more of bug 1550836 adding the string in the first place.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Bug 1550836 landed in 78, you're pointing to a language pack that targets 77. That string is expected to be missing if it wasn't translated yet.
Can you clarify exactly what you tested and how?
Comment 6•4 years ago
|
||
Right, I think this bug might be invalid/wontfix (?) as using langpacks on nightly will run into these types of issues of missing new strings. Although I suppose the nightly-packaged en-US strings are available.
Comment 7•4 years ago
|
||
(In reply to Ed Lee :Mardak from comment #6)
Right, I think this bug might be invalid/wontfix (?) as using langpacks on nightly will run into these types of issues of missing new strings. Although I suppose the nightly-packaged en-US strings are available.
Yes, but unless we switch to using fluent, those strings will not be used - it'll just try to use the (incomplete) en-GB .properties file.
:flod, is this invalid? For complete builds in a particular locale, l10n merging will fix this, right?
Comment 8•4 years ago
•
|
||
I think we still understand very little about this bug.
Comment 2 shows that Marcin is running an en-GB build, language packs are not involved.
.properties files (like DTDs) are "completed" by compare-locales at build time, that's why we can ran partially localized builds in the first place.
@Martin
Are you still seeing this error? If so
- Can you attach here the raw data from
about:support
? - Do you remember if you installed the en-GB version of Nightly?
- Can you open in the address bar
chrome://global/locale/aboutReader.properties
. Do you see a stringreaderView.savetopocket.label
? What's the value?
Comment 10•4 years ago
|
||
To answer the other questions:
No, I'm pretty sure I downloaded the en-US version of Nightly. Later I fiddled with the settings to get en-GB spellcheck and changed a bunch of things related to language.
I don't see the string you mention. Here's the entire readerView
section from that file:
# These are used for the Reader View toolbar button and the menuitem within the
# View menu.
readerView.enter=Enter Reader View
readerView.enter.accesskey=R
readerView.close=Close Reader View
readerView.close.accesskey=R
Comment 11•4 years ago
|
||
Can you confirm if you see a Languages tab in about:addons? If so, what's the content?
If you have a language pack, do you remember what you did to install it?
Comment 12•4 years ago
|
||
Yes, I have an English (GB) language pack installed there. I'm not sure what I did to install it, but I doubt it was anything like loading from a file or anything. I had to either install it from settings if that's possible, or from addons.mozilla.org.
Comment 13•4 years ago
|
||
Can you remove that language pack, or disable it? That should fix the problem.
I have no clue how you could get into this situation:
- AMO only has language packs for release, i.e. the maximum version you can get right now is 77.
- The language switcher in settings is disabled for Nightly, and downloads language packs from AMO, so it has the same limitations when it comes to supported versions.
- Given you're on Nightly, the only way to get a compatible language pack should be from FTP (with compatibility only to 79).
Comment 14•4 years ago
|
||
I believe there's a major problem with compatibility checks.
Can you click on the language and copy the version here?
Comment 15•4 years ago
|
||
The version is 77.0buildid20200504222419
.
I just removed it and re-added. Here's what I did to re-add:
- go to Preferences > General > Language
- expand language drop down
- choose Search for more languages...
- expand Select a language to add... dropdown
- choose English (United Kingdom)
- click Add
It downloads it without a peep.
Can confirm removing the language pack and restarting Nightly fixes the issue. I can now see the Pocket button.
Comment 16•4 years ago
|
||
Uh, while both the language switcher and language download are disabled by default, this shouldn't work.
I'm going to mark this as dupe of bug 1646016, I'm afraid we're going to have a few cases :-\ Going to investigate the language switcher, given it might be a separate bug.
Description
•