1049108 - Change default search provider to Bing

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Karen Rudnitski [:kar]]

Before this gets uplifted, we need to confirm the target date in order to ensure key stakeholders are aware of the change.

Please prepare to change the default search provider to be:
1. Bing
2. Yahoo
3. Google
4. Amazon
5. <rest of the default order>
...

Please make this change for en-US, en-GB, de, es-ES and fr only.

We have dispensation to run traffic through https for mobile only - we are NOT allowed to divert desktop traffic to https yet. That will be in a different bug.

Can we confirm how the code is currently written for the following scenarios? 

- If I am an existing Firefox for Android user and I haven't changed my default engine or order at all, can we change the default provider?
- If I am an existing Firefox for Android user and I have changed my default to something else and then maybe even changed it back to Google, can we treat this as a user who has changed and chosen their default?

Final consensus will be how to best handle the above scenarios in terms of expectation. On the Beta channel, I propose we change the default provider from Google to Ping for existing users and then see how many people change it back.

To reiterate, no change should be pushed to the Beta code until we have locked down how this will work and the expected uplift date to ensure we are all prepared for the change (including Bing and SUMO / feedback etc)

Comment 1

[Francesco Lodolo [:flod]]

(In reply to Karen Rudnitski [:kar] from comment #0)
> We have dispensation to run traffic through https for mobile only - we are
> NOT allowed to divert desktop traffic to https yet. That will be in a
> different bug.

Just to be sure it's clear: unlike Yahoo, for Bing we use the en-US version for all locales, so a switch to https will happen for all locales on mobile for that branch, not just the requested 5.

Comment 2

[Karen Rudnitski [:kar]]

Given we have the OK to run mobile traffic through https, that is fine. 

And just so that I am clear, if a German user hits Bing, Bing knows this and sends them relevant results, right? That's how I seem to remember it happening.

What about a more obscure locale? Or should I be asking Bing this? :)

Comment 3

[Francesco Lodolo [:flod]]

(In reply to Karen Rudnitski [:kar] from comment #2)
> And just so that I am clear, if a German user hits Bing, Bing knows this and
> sends them relevant results, right? That's how I seem to remember it
> happening.

Yes.

> What about a more obscure locale? Or should I be asking Bing this? :)

I haven't heard complaints about Google (actually, there was Kurdish at some point) or Bing giving results in the wrong locale, so I assume they're doing their job correctly. Not sure what happens for smaller locales, I'd hope they get redirected to the "nearest" locale (e.g. hsb->de), not en-US.

Comment 4

[Karen Rudnitski [:kar]]

Thanks. I'll send that question over to Bing

Comment 5

[Axel Hecht [:Pike]]

FTR, Kurdish was this: We have Latin script (on desktop that is), and google served arabic script. And people being able to read one hardly read the other, or that's what we've been told back then. But it's also been a while.

Comment 6

[Karen Rudnitski [:kar]]

Ok, another question. We want to speed this through the process as quick as possible. But we (UX and Product) think it's a good idea to inform existing users that we're changing their default (only if they haven't touched their default to date). Ian has an idea which can be picked up (or over-ruled) by the rest of our UX team, but for expediency sake: can we JUST change the default for en-US, en-GB, fr, de and es-ES and allow the others to be untouched? 

I'm thinking along the lines of expediting fr, es and de only in order to not overwhelm the localizers to get this into the code ASAP. What thoughts do we have on how best to tackle localizing a phrase relating to this change with as little pain as possible? Suggestions welcome!

Comment 7

[Axel Hecht [:Pike]]

We don't have tooling to expose strings to just a few locales. It's all or none.

I suggested stunts to the translation experiment folks to hard-code a few localized strings in content and manually do l10n in only a few languages, but that's ughly.

Anywho, before we talk about uplifting and late-l10n changes and all that, can we get the coding questions in comment 0 answered/resolved?

Also, this seems to open an interesting conversation with the community, who's leading that? Karen?

Comment 8

[Kev Needham [:kev]]

> I'm thinking along the lines of expediting fr, es and de only in order to
> not overwhelm the localizers to get this into the code ASAP. What thoughts
> do we have on how best to tackle localizing a phrase relating to this change
> with as little pain as possible? Suggestions welcome!

Just to throw it out there, is there any reason why it would be added in code vs. the awesome screen/whatsnew/tiles? You get a little more flexibility with info you can deliver, too. If Android works the same as desktop, the search order and defaults can be set per locale in region.properties (I think it does, but it's been a while).

Comment 9

[Francesco Lodolo [:flod]]

Default searchplugin is per locale, so no problem in changing it only for some languages.

But note that we are only 2 weeks away from beta freeze for l10n, it's August, and we need to involve the community in the discussion. Timing doesn't look great.

Comment 10

[Aaron Train [:aaronmt]]

(In reply to Karen Rudnitski [:kar] from comment #0)
> - If I am an existing Firefox for Android user and I haven't changed my
> default engine or order at all, can we change the default provider?
> - If I am an existing Firefox for Android user and I have changed my default
> to something else and then maybe even changed it back to Google, can we
> treat this as a user who has changed and chosen their default?

I'm of the mindset that changing something as core as a user's preferred search engine out from underneath them without permission is not very nice. Are we providing an opt-in?

Comment 11

[:Margaret Leibovic]

As a first step, I think we should write an en-US patch to land on Nightly and test to make sure the default engine is changed as we would expect. This would also help us get some feedback from users.

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to :Margaret Leibovic from comment #11)
> As a first step, I think we should write an en-US patch to land on Nightly
> and test to make sure the default engine is changed as we would expect. This
> would also help us get some feedback from users.

Agreed. Perfect first step.

Comment 13

[:Margaret Leibovic]

Attachment: en-US patch

It looks like this https endpoint does not work for search suggestions. Is there some different endpoint that we're supposed to use?

Also, we should add some logic to make sure this doesn't ride its way to release. Does anyone know if we can use build defines in .properties files to specify different behaviors? Or I could create a new .properties file to be used on non-release builds, and then just put the build define logic in mobile.js.

Comment 14

[:Margaret Leibovic]

kar and/or mconnor, can you help sort out the https suggestions issue? Also, what should the order of the remaining engines be? In this patch I just swapped Google and Bing.

Comment 15

[Joanne Nagel]

I have reached out to the Bing folks for help with the suggestions issue and cc'd mconnor.  Also, the order should be Bing, Yahoo, Google,...  Thanks, Joanne

Comment 16

[Axel Hecht [:Pike]]

(In reply to :Margaret Leibovic from comment #13)> 
> Also, we should add some logic to make sure this doesn't ride its way to
> release. Does anyone know if we can use build defines in .properties files
> to specify different behaviors? Or I could create a new .properties file to
> be used on non-release builds, and then just put the build define logic in
> mobile.js.

We don't support build defines in .properties.

That said, do we need to actually land this in Nightly to do the testing that's needed?

Comment 17

[:Margaret Leibovic]

(In reply to Axel Hecht [:Pike] from comment #16)
> (In reply to :Margaret Leibovic from comment #13)> 
> > Also, we should add some logic to make sure this doesn't ride its way to
> > release. Does anyone know if we can use build defines in .properties files
> > to specify different behaviors? Or I could create a new .properties file to
> > be used on non-release builds, and then just put the build define logic in
> > mobile.js.
> 
> We don't support build defines in .properties.
> 
> That said, do we need to actually land this in Nightly to do the testing
> that's needed?

Well, regardless I think we should land this in Nightly and Aurora before landing in Beta, since that would just be standard practice. My main concern is that we don't land a patch on Beta that will get merged to released before we want it to be.

We could always just back this out as part of the merge process, but we would also need to make sure all locales that are trying out this experiment are also reverted.

Comment 18

[Axel Hecht [:Pike]]

Backing out on localizations would be a horrible amount of work, and likely break a bunch of assumptions in the release automation processes. That sounds incredibly risky.

Comment 19

[Karen Rudnitski [:kar]]

How's this. Put this into nightly/aurora as soon as possible while we still sort out some of the other bits around this (like the snippet, how to handle the search suggestion endpoints, etc)? Then we can uplift to beta when we know that we'll have all of our ducks lined up in a row (including sumo articles, etc)

Axel/Jeff - you mentioned earlier giving a heads' up to the community. In what form do you suggest we let them know?

Note for the bug: we won't be able to perform a/b testing on this round since we're not coded to do so (like we are on desktop) and we don't want to hold back.

Comment 20

[:Margaret Leibovic]

I still don't think we can land this in Nightly/Aurora without https suggestions working, so that seems like the main blocker.

Also, to restrict this to Nightly/Aurora we'll still need something in place to prevent it riding the trains, and I'm just not sure of the best way to do that with these localized prefs. As Axel mentioned in comment 18, backing things out of locales right after a merge is risky.

Axel/Jeff, do have any ideas for how to do that? We could create an alternate "experimental" .properties file to be used for the search prefs on Aurora/Beta. But the seems like it could be annoying, since we would only want this experiment in a few locales, but all locales would need to make this file.

Perhaps we could just make alternate pref names like "browser.search.defaultenginename.experiment", then on startup we can have some check to see if we're on Nightly/Aurora and if this pref exists, flip "browser.search.defaultenginename". However, this seems like it would have its own set of risks, and we'd want to make sure we're just setting the default pref, not overriding any user set pref.

Thoughts?

Comment 21

[Axel Hecht [:Pike]]

How about using a flag on build time, and use a fake package, with chrome overlays for region.properties, all coming out of mozilla-central?

Karen, for community interaction, Jeff and I found a few threads with you on them, once we have a verified technical behavior, it'd be good to drive those threads forward with a concrete description.

Comment 22

[Aaron Train [:aaronmt]]

Not happening on 32; convince me on IRC otherwise.

Comment 23

[Axel Hecht [:Pike]]

Hrm. So the chrome registry hack probably won't work for the multi-locale builds, at least not if we're making them sparse:

The overlay works on the chrome url level, and then there's the locale negotiation of the chrome registry.

So region.properties -> overlay.properties -> localization thereof

Now, if we don't ship a localization of overlay.properties, it won't be registered in teh manifest, and the selected locale will fall back to en-US, and not to the original localization of region.properties.

Only workaround would be to ship-all-the-things, and modify just the tested locales in the overlay package.

Comment 24

[Karen Rudnitski [:kar]]

To summarize some of what's above and to lay out next steps.

New search order should be:
Bing
Yahoo
Google
<alphabetical list for remainder>

To address the main blocker (https for search suggestions): this should be resolved later in September. We'll send out exact date once confidence levels are a bit higher, but let's assume 3rd week of September for now.

1. Prepare SUMO landing page (bug 1056653)

2. Prepare campaign snippet to run on Nightly and Aurora (bug 1056651). [ Deploy after we have made the change, however, so as not to dilute the message to these test users (unlikely, but I'd like to see how coordinated we can get, too :) ). ]

3. Prepare code to land only on nightly and aurora first, but only after we have verified it works as expected (and, of course, after Bing lets us know they're ready on their side later this September). Let's deploy for all locales here (since it's nightly / aurora) to see if we get any feedback on weird behaviour from as many locations as possible (knowing it's en-US centric for this audience - have to start somewhere though!). 

4. Monitor for feedback closely here. After a week, let's evaluate timing to uplift to Beta. 

Questions for my clarity:
A) did we say that we COULD just deploy to certain locales in the end if we wanted?
B) Axel, could you send me an appropriate thread or forum that I can use to inform the community of our intention?

This will likely get picked up by press once I send a note out to the community, so I am also looping in PR at this stage (via email) to prepare statements, FAQs, etc.

Comment 25

[:Margaret Leibovic]

Comment on attachment 8471877 [details] [diff] [review]
en-US patch

Once bug 958874 is fixed, this patch should work to update en-US on Nightly.

However, I'll need to work with Axel to figure out the appropriate overrides approach if we want to uplift this change to beta but prevent it from riding to release.

Alternately, we could only land this on beta for very few locales, such that we could back it out before release, but that still feels pretty risky.

Comment 26

[Mark Finkle (:mfinkle) (use needinfo?)]

The current patch in bug 958874 handles all of the changes to bing.xml, so this patch only needs to handle setting the default

Comment 27

[:Margaret Leibovic]

Attachment: switch default engine to bing

I'll wait for a go-ahead before landing this.

Comment 28

[:Margaret Leibovic]

After more discussion with the product team, we decided we're not going to do this. Closing out the bug.