808732 - Enable user to change default search provider in browser

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Browser, defect, P1)

Description

[Matt Basta [:basta]]

There is currently no way to specify which search provider you wish to use. Users that do not wish to use the default provider have no way to change which provider they are using.

Comment 1

[Ben Francis [:benfrancis]]

This is intentional, in v1 you don't get to choose. This is likely to come later in v2.

Comment 2

[Matt Basta [:basta]]

Correct me if I'm wrong, but this seems like a massive divergence from the Mozilla mission towards giving users tools "to take control of their online lives," especially when the means to allow for the user to choose one of a few providers is conceptually trivial.

Comment 3

[[:fabrice] Fabrice Desré]

Indeed you're wrong. No one said we're not gonna do this at some point, just that it's too late to add this feature for v1. But of course we take patches ;)

Comment 4

[Rob MacDonald [:robmac]]

I've posted a DRAFT flow for this bug to dropbox, subject to review by Larissa and the Browser UX team. 

https://www.dropbox.com/s/0rcqu5nilxt4xts/browser-defaultsearch-130301-DRAFT.pdf

The file is posted to give you a sense of our current direction and will be updated once additional UX reviews have taken place. In the meantime, feel free to send me your questions and/or feedback.

Thanks!
Rob

Comment 5

[Matt Basta [:basta]]

Will it be a planned feature to allow users to add/remove opensearch providers from that list as they can with FX for Android and desktop?

Comment 6

[Rob MacDonald [:robmac]]

(In reply to Matt Basta [:basta] from comment #5)
> Will it be a planned feature to allow users to add/remove opensearch
> providers from that list as they can with FX for Android and desktop?

That's a great question. I included that in an updated version of the screens and posted it here:

https://www.dropbox.com/s/w5ouzvfeb4u3vnt/browser-defaultsearch.pdf

It's listed on the last few pages as a "UX Proposal" that's not in scope as it's not part of the user story. However, it's definitely worth considering. 

Also, Larissa has reviewed the document for alignment with Android. The only outstanding item is that users need to be able to opt out of search suggestions due to privacy issues. The plan is to present users with a prompt and to add a switch to settings. I'll be reviewing these on Android and adding them this week.

Comment 7

[Rob MacDonald [:robmac]]

Hi everyone...

The spec has been updated with the first time use (opt-in) prompts as well as detailed annotations. Let me know if you have any questions or suggestions!

https://www.dropbox.com/s/w5ouzvfeb4u3vnt/browser-defaultsearch.pdf

- Rob

Comment 8

[Rob MacDonald [:robmac]]

Also, Przemek has posted his visual specs here:

https://www.dropbox.com/sh/a2ve47f83ib5rp3/yx3Lao46oF/Bowser%20Search%20Suggestion/Final

Comment 9

[Ben Francis [:benfrancis]]

(In reply to Rob MacDonald [:robmac] from comment #7)
> The spec has been updated with the first time use (opt-in) prompts as well
> as detailed annotations. Let me know if you have any questions or
> suggestions!

This looks great, and would bring us more in line with Firefox for Android.

However, there are several features conflated into this one UX spec which I believe are out of scope for this bug and need to be tracked separately.

The spec covers:
* Change default search provider (this bug)
* Adding support for search suggestions for at least one provider (potentially a lot of work)
* The ability to turn search suggestions on and off
* Changes to the "search results view" from what we currently have, including supporting multiple providers

I would argue that each of these really need to be tracked and prioritised as separate user stories as this is too much work to estimate in one go.

Comment 10

[Peter Dolanjski [:pdol]]

Ben, would you be able to provide an estimate for the basic functionality of being able to change the default search engine in the Browser settings menu?

Comment 12

[Ben Francis [:benfrancis]]

(In reply to Peter Dolanjski [:pdol] from comment #10)
> Ben, would you be able to provide an estimate for the basic functionality of
> being able to change the default search engine in the Browser settings menu?

Just adding an option in browser settings shouldn't be too difficult, although we don't actually currently have a system to store settings in the browser so we'd need to create a new IndexedDB store for that purpose. We'd also need a list of which search engines should be in the list (assuming that there's no UI for users to add their own).

I would estimate this as LOE:S

Comment 13

[Rob MacDonald [:robmac]]

I've updated the spec to flag any non v1.1 features as UX proposals that are not in scope...

https://www.dropbox.com/s/w5ouzvfeb4u3vnt/browser-defaultsearch.pdf

Let me know if you have any questions or concerns.

- Rob

Comment 14

[[e-mail]]

added an basic task in bug 856014 before saw this issue...

Comment 16

[Rob MacDonald [:robmac]]

Reposting the link to the spec as it appears to have been broken. 

https://www.dropbox.com/s/dkg6rjgmsq6jpwj/browser-defaultsearch.pdf

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Could we at lease move the string to mozSettings first? That would at least make people who build Gaia easier to make the change.

Comment 18

[[:fabrice] Fabrice Desré]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #17)
> Could we at lease move the string to mozSettings first? That would at least
> make people who build Gaia easier to make the change.

Or in a json file like apps/browser/js/init.json since the UX spec doesn't specify that other apps need to access these values.

Comment 19

[[e-mail]]

bug 840210 is tracked to patch apps/browser/js/init.json for build time customization

Comment 20

[Ben Francis [:benfrancis]]

Product: Can we get a list of the search providers which the user should be able to choose from?

I suggest we start with just page 5 of the UX spec which addresses the feature described in this bug, then file follow-ups for the other parts.

User Story: As a user I want to change the default search provider in the browser so that I'm not forced to carry out my web searches using an evil corporation that kills puppies.

Comment 21

[Chris Lee [:clee]]

This is a valuable feature.  I will follow up with our partner teams to gather the right set of search providers.

Comment 22

[Robert Kaiser]

I think we should not end up with a hardcoded list (we can have a default list possibly, though) but we should allow installation of OpenSearch providers at will.
Not sure if that should be isolated to the browser app or should be on a system/gaia level.

Comment 23

[[:fabrice] Fabrice Desré]

(In reply to Robert Kaiser (:[e-mail]) [away until early June] from comment #22)
> I think we should not end up with a hardcoded list (we can have a default
> list possibly, though) but we should allow installation of OpenSearch
> providers at will.
> Not sure if that should be isolated to the browser app or should be on a
> system/gaia level.

I agree. We need to expose the <link rel=search> links to gaia, extending the mozbrowser API.

Comment 24

[Ben Francis [:benfrancis]]

(In reply to Robert Kaiser (:[e-mail]) [away until early June] from comment #22)
> I think we should not end up with a hardcoded list (we can have a default
> list possibly, though) but we should allow installation of OpenSearch
> providers at will.

Sounds good, please file a separate bug for supporting adding custom search engines via OpenSearch.

Comment 25

[Robert Kaiser]

(In reply to Ben Francis [:benfrancis] from comment #24)
> Sounds good, please file a separate bug for supporting adding custom search
> engines via OpenSearch.

Bug 883002.

Comment 26

[Ben Francis [:benfrancis]]

We can implement this without OpenSearch. This is really sprint ready though we could do with a list of search providers from Product.

Comment 27

[Matthew N. [:MattN]]

Is the plan to use the existing toolkit search service? You would get the OpenSearch support for free with that. Both desktop and Android use it.

Comment 29

[Ben Francis [:benfrancis]]

From bug 889587

As a user when I am surfing the web, the Firefox OS browser should allow me to select from a list of search providers so that I may have a tailored search experience based on my preferred provider.

Comment 30

[Robert Kaiser]

(In reply to Ben Francis [:benfrancis] from comment #26)
> We can implement this without OpenSearch.

I don't believe we should invent something else when an open, cross-browser standard already exist for exactly that purpose.

Comment 31

[[:fabrice] Fabrice Desré]

(In reply to Matthew N. [:MattN] from comment #27)
> Is the plan to use the existing toolkit search service? You would get the
> OpenSearch support for free with that. Both desktop and Android use it.

We could expose a subset of https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIBrowserSearchService through the mozbrowser API, yes. The alternative is to only add in mozbrowser the ability to get events when finding a <link ...> element and let the browser app implement all the search support.

Comment 32

[Ben Francis [:benfrancis]]

(In reply to Robert Kaiser (:[e-mail]) from comment #30)
> I don't believe we should invent something else when an open, cross-browser
> standard already exist for exactly that purpose.

I wasn't suggesting we did that. Just that Open Search support is covered in bug 883002

We could implement a list of common search providers which are set at build time for the user to choose from without implementing the whole of Open Search. That would at least be an improvement on what we have now.

When we do Open Search I think we could probably implement most of it in the browser app and just expose events for <link> elements as Fabrice suggests.

Comment 33

[ffos-browser]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/53548743

Comment 34

[Ben Francis [:benfrancis]]

Hi Karen,

Is there anything left to do to make this feature sprint ready? The work I'm doing in bug 840210 will lay the groundwork to define a list of search providers at build time for the user to choose from. Then we could simply implement the selection box in browser settings shown on page 5 of https://www.dropbox.com/s/dkg6rjgmsq6jpwj/browser-defaultsearch.pdf for the UI.

Allowing users to choose their search provider seems like a fundamental requirement for a Firefox browser, and this is a very simple way of achieving that without getting into any tricky search suggestions and multiple provider issues.

Once we have this in place, we can move on to giving users even more choice by allowing them to add in extra search providers via OpenSearch in bug 897445. The platform support Fabrice added in bug 883002 will be a big help, and Kevin's prototype in bug 898352 shows that it's possible.

Comment 35

[Karen Rudnitski [:kar]]

Circulated via Ian and Francis as well. From product / UX perspective, we should be good to go to get this started. Brad - please let me know if this is sprint-ready from your perspective.

Comment 36

[Ben Francis [:benfrancis]]

Attachment: 808732.diff

This patch is on top of the patch in bug 840210 so I'll rebase against master and send a pull request once that patch lands.

Comment 37

[Ben Francis [:benfrancis]]

Attachment: 808732.diff

Oops. missed a string localisation. Sorry for the noise.

Comment 38

[Ben Francis [:benfrancis]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/11534

Sent pull request

Comment 39

[Dale Harvey (:daleharvey)]

Comment on attachment 790377 [details] [diff] [review]
https://github.com/mozilla-b2g/gaia/pull/11534

Minor nit in there that we may as well fix on the way in, but looks good, cheers

Comment 40

[Ben Francis [:benfrancis]]

Merged into master in https://github.com/mozilla-b2g/gaia/commit/f82d1454f03d930ae23c0cf00251ecf8d895330d

Comment 42

[Ben Francis [:benfrancis]]

Waiting for acceptance

Comment 43

[Karen Rudnitski [:kar]]

Ben - just looking at UX specs, the only thing that I see is that we have 'ok' instead of 'cancel' after clicking on your default search engine. Was that out of a conversation you had with UX?

Comment 44

[Karen Rudnitski [:kar]]

Francis, Ian - there seems to be a bit of inconsistency with how the 'cancel' / 'ok' buttons are handled. Some have just 'ok', some have both 'cancel' and 'ok', and this spec asks for 'cancel'.

I am personally comfortable with it saying 'ok' instead of 'cancel', but wanted to know whether to accept this bug as it is written and we write a new one to fix up the buttons, or whether you had a strong opinion either way.

Thanks, Karen

Comment 45

[Ben Francis [:benfrancis]]

Oh sorry, I forgot to mention that. It's actually a system component, that's how Firefox OS renders <select> boxes. Changing it to cancel would mean re-implementing that UI inside the browser app and copying & pasting all the code except for the label. I opted to go for the system component for consistency.

Comment 46

[Karen Rudnitski [:kar]]

Thanks, Ben!

Comment 47

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Forgot to mark this verified:
Gaia   73a64d360f0ed135fcca205c6292e9219e085413
SourceStamp e3c84e9f2490
BuildID 20131002040206
Version 27.0a1
Buri