Use Region.current engine in fetchEngineConfiguration
Categories
(Firefox :: Search, task, P3)
Tracking
()
People
(Reporter: daleharvey, Assigned: daleharvey)
References
(Blocks 1 open bug)
Details
Attachments
(1 obsolete file)
+++ This bug was initially created as a clone of Bug #1634580 +++
When we start fetching the region more often we can use the up to date region to send the correct region specific code to engines without reloading the engine list
This means we would probably need to keep track of an additional region, current + currently applied to the engine list. Can possibly add a new field to the configuration "regionOverrides" that is stored in the engine object
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Are you thinking of using different codes on a temporary basis, or a permanent if the region changes?
If it is permanent (until next change), I think after we've done the work on maybeReloadEngines, reloading the engine list wouldn't be as invasive as it was previously.
It'd also mean the user would get US versions of websites rather than regions.
Assignee | ||
Comment 2•4 years ago
|
||
I am not sure what you mean by temporary / permanent, I think in some cases, particularly google, this can be the way in which we specify the codes instead of having seperate params matched in the appliesTo section.
Even when we refactor maybeReloadEngines, we still arent going to immediately change the users engine list every time the region changes and its not for certain we would ever want to do that for when the user goes on holiday etc. The cache busting patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1627555 will update the users home region with a minimum 2 week delay at the moment.
I think with the region changes and maybeReloadEngines refactor we may want to make some product changes to what engines we show to the user and how we update them, but I think if we decouple that from what codes we are sending we dont need to make any tradeoffs between the accuracy of the codes and what makes the most sense for the user.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Taking a look at this and hit against some problems with complexity and telemetryId, I have another approach in mind and will reuse this bug to do it
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
I think given the increases we have already made with revenue efficiency and the increased complexity this is going to bring, going to shelve it until it becomes a product requirement.
Updated•3 years ago
|
Description
•