User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

• I created a new profile on Linux. That was it.

So I compare the 2 profiles. I found out the entire 'browser.search.region' is missing.
After add this in about:config and restart, it was available

I tasted it on Windows too, but there is no problem. So it just on Linux

Actual results:

Suddenly the option for Recommended by Pocket is not available

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Scott, can you repro?

No I cannot reproduce.

A few things come to mind.

1. Does this happen on every new profile? Or was it only once.
2. If the region isn't available, a lot of things are not going to be available.
3. On a new profile, I believe the region is set async, so it could be delayed in some situations.

There is a meta bug for improving region detection https://bugzilla.mozilla.org/show_bug.cgi?id=1617907

Not sure when these pieces are landing or how it's improving, but worth looking at.

I am working on region detection improvements however the case here is possible to run into, while it shouldnt happen very often its always possible for the location services request to fail (client may not be connected to the internet etc), so if possible consumers of the region should be able to handle the cases where there is no defined region, if the only option in this case is to not show recommendations then there is not much else we can do, the work in ^ will make it easier to retry the region fetching when it fails if that is shown to be a common issue.

(In reply to Scott [:thecount] Downe from comment #3)

No I cannot reproduce.

A few things come to mind.

1. Does this happen on every new profile? Or was it only once.
2. If the region isn't available, a lot of things are not going to be available.
3. On a new profile, I believe the region is set async, so it could be delayed in some situations.

1 - Yes. On every new profil on every Linux system that i tested.
On dualboot Linux-Win System (Xubuntu 20.04) . On virtual system with Win as host in Virtualbox with Ubuntu 18.04 and Xubuntu 20.04.
3 - How long does it take?

(In reply to Dale Harvey (:daleharvey) from comment #5)

I am working on region detection improvements however the case here is possible to run into, while it shouldnt happen very often its always possible for the location services request to fail (client may not be connected to the internet etc), so if possible consumers of the region should be able to handle the cases where there is no defined region, if the only option in this case is to not show recommendations then there is not much else we can do, the work in ^ will make it easier to retry the region fetching when it fails if that is shown to be a common issue.

When the location services request fail, why can the default region not be the language region?

1 - Yes. On every new profil on every Linux system that i tested.

If its a repeated thing that definitely shouldnt happen, what is the value for "geo.provider-country.network.url" when you install? can you connect to that URL? Can you chck the browser console to see if any errors appear? The region fetch happens quite early in the startup flow so should be available by the time you use the UI

When the location services request fail, why can the default region not be the language region?

If thats a fallback that works for Pocket they can do so, however conflating locale with region has been a mistake previously and we have been making efforts to uncouple them, I dont think its something we would want to enforce system wide

(To see differences, I test it with Xubuntu and Win)
In about:config "geo.provider-country.network.url" = "https://location.services.mozilla.com/v1/country?key=%MOZILLA_API_KEY%"

If I connect "https://location.services.mozilla.com/v1/country?key=%MOZILLA_API_KEY%":
{"error":{"errors":[{"domain":"usageLimits","reason":"keyInvalid","message":"Missing or invalid API key."}],"code":400,"message":"Missing or invalid API key."}}
In console I see just one erro: "https://location.services.mozilla.com/favicon.ico is blocket" but I think that doesn't matter (is on both)

If I open "https://whatismyipaddress.com" they see my place

I made another interesting discovery:
it works if I use Firefox from "https://ftp.mozilla.org/pub/firefox/releases/76.0.1/linux-x86_64/" instead of Linux store

Am I the one that's not working?

This sounds like the ubuntu store version doesnt have a valid API key, I know there has been issues with keys being revoked or not packaged correctly, I will setup my linux image to test but in the meantime John is this a known / recognisable problem?

The value https://location.services.mozilla.com/v1/country?key=%MOZILLA_API_KEY% is correct, and the same as Mozilla's Firefox distribution. Firefox replaces %MOZILLA_API_KEY% before making the call (see URLFormatter.jsm). The placeholder %MOZILLA_API_KEY% is an invalid key, so this is the expected response from MLS.

The default is no-mozilla-api-key, but a "real" value is supposed to be baked in at build time. I'm not 100% sure how this works, or how you could verify the value in a binary. Here's some test code that may trigger the memory of a Firefox developer or packager.

ok so this is actually "expected" behaviour, partner distributions of Firefox turn geoSpecificDefaults off @ https://github.com/mozilla-partners/canonical/blob/master/desktop/ubuntu/distribution/distribution.ini

However the work in https://bugzilla.mozilla.org/show_bug.cgi?id=1617907 is decoupling the region fetching from the search service and so region fetching for will start to work despite the value of geoSpecificDefaults, I will dupe this to the bug thats going to change that behaviour

Ah that makes sense, I use Fedora, but because I'm building and testing stuff in Firefox, I tend to download the browser directly, and I don't use the package manager. Super helpful info.

Is it just Ubuntu that has the distribution specification, and something like Fedora would not?

I personally would find my life mush simpler if we could just turn pocket on/off based on locale, but we're starting to look at the implications of turning pocket stories on in non US regions that use the en-US locale.

One piece that doesn't quite add up for me yet, something about this report seems new. We had another report reach out to us directly recently with the same issue.

If this is the distribution policy, this would have been the case for a long time, right? If it's something they are hitting recently, something might have changed that caused this? Could also be a coincidence.

It was disabled in 2018 - https://github.com/mozilla-partners/canonical/commit/437e9b9fe422b65f7c7f5fd2723002a85c10e5b2#diff-1e04e4dae10096cc9d1c903c7186f7ba and there was some churn around this in 2015 as well https://hg.mozilla.org/releases/mozilla-release/rev/37ea9e22ac42, its hard to track exactly when this would have been enabled / disabled by default in ubuntu

Fedora does its own customisations when packaging but doesnt seem to disable geoSpecificDefaults @ https://src.fedoraproject.org/rpms/firefox/blob/df0172c5dab9b48efe2f483f26137623ccd5ac9b/f/firefox-redhat-default-prefs.js