Closed Bug 1652805 Opened 6 months ago Closed 5 months ago

Generic English feed enabled for en-US browsers outside of the US


(Firefox :: New Tab Page, enhancement, P1)




81 Branch
81.2 - Aug 10 - Aug 23
Tracking Status
firefox81 --- verified


(Reporter: thecount, Assigned: thecount)


(Blocks 1 open bug)



(1 file)

Proposal: We want to be able to have non US feeds for en-US browsers outside of the US.

Problem: There are only three English locale browser builds, en-US, en-CA, and en-GB, the rest use one of those three. Our current system only looks at locale, limiting our feeds to one of those three.

For example:

  1. en-US browsers in the US region get the en-US feed. Pretty logical.
  2. en-GB browsers in the GB region get the en-GB feed. Also works.
  3. de browsers in the DE region get the de feed. This works because it's not English.

These all make sense, but if we keep expanding these, it starts to get weird.

  1. en-GB browsers in the IR region get the en-GB feed. Not an Irish or generic feed.
  2. en-US browsers in the IN region get the en-US feed. not en English India feed or generic feed.

Would an Irish or India feed make more sense? Currently we cannot do that.


  1. Let the server look at the geo/lang in the header, or similar, and the locale we pass. With these three bits of info, the server can make the decision on what to return.
  2. Have the client pass along region with locale. Server can then make the decision on what to pass.
  3. Have the client infer and update the locale code based on region. Example, if the client sees the locale code en-US and region as IR, we can pass in en-IR. This seems brittle to me, and also confusing because it suggests a browser locale that doesn't exist.

Scott and I talked live. (2) is the right solution, and we can add the new parameter called "region" to the request.

(1) Would be prohibitively expensive, because geo is derived from IP addresses, which would prevent us from using a CDN cache.
(3) Would be brittle, and would generate locales that are invalid according to the ISO standard, for example when users in NL have an en-US browser.

Assignee: nobody → sdowne
Iteration: --- → 80.2 - July 13 - July 26
Priority: -- → P1

To test:

Mostly we want to do regression testing here. Make sure stories still show where they are expected. This is because the value we're adding to the request isn't being used by the server yet, so it should just do nothing, but stories should still be displayed.

Another thing to test:

  1. Set browser.newtabpage.activity-stream.asrouter.devtoolsEnabled to true
  2. Open the multi process debugger
  3. Navigate to about:newtab#devtools-ds
  4. Click refresh cache
  5. Look in the network tab in the multi process debugger.

Expected: Should see a request to, looking at that requests get params, should see region=CA or some other reasonable region value.

Iteration: 80.2 - July 13 - July 26 → 81.1 - July 27 - Aug 09
Iteration: 81.1 - July 27 - Aug 09 → 81.2 - Aug 10 - Aug 23
Pushed by
Pass along region for newtab story requests. r=gvn
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Blocks: 1660035

I have verified this enhancement and I can confirm the following:

  • The "Recommended by Pocket" stories are correctly displayed for the "IE" and "IN" regions.
  • The "Region" parameter is successfully displayed in the "" request (E.G.

Verified using the latest Firefox Nightly en-US and en-GB locale builds (81.0a1 Build ID - 20200823211533) installed on Windows 10 x64, Mac 10.15, and Ubuntu 18.04 x64.

You need to log in before you can comment on or make changes to this bug.