Closed Bug 1643067 Opened 4 years ago Closed 4 years ago

save to pocket button not visible even though pref is true

Categories

(Firefox :: Pocket, defect, P2)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1646016

People

(Reporter: thecount, Assigned: thecount)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached image js-err.png

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: nobody → sdowne
Severity: -- → S3
Priority: -- → P2

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"

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"

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?

Regressed by: 1637498

Probably more of bug 1550836 adding the string in the first place.

Regressed by: 1550836
No longer regressed by: 1637498
Has Regression Range: --- → yes
Keywords: regression

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?

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.

(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?

Flags: needinfo?(francesco.lodolo)

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 string readerView.savetopocket.label? What's the value?
Flags: needinfo?(francesco.lodolo) → needinfo?(marcin)
Attached file about-support.json

here's the raw about:support info

Flags: needinfo?(marcin)

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

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?

Attached image image.png

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.

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).

I believe there's a major problem with compatibility checks.

Can you click on the language and copy the version here?

The version is 77.0buildid20200504222419.

I just removed it and re-added. Here's what I did to re-add:

  1. go to Preferences > General > Language
  2. expand language drop down
  3. choose Search for more languages...
  4. expand Select a language to add... dropdown
  5. choose English (United Kingdom)
  6. 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.

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.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: