Enable user to change default search provider in browser

VERIFIED FIXED

Status

P1
normal
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: basta, Assigned: benfrancis)

Tracking

({feature, productwanted})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: interaction c=browser u=user [sprintready] [UCID:Browser8, FT:Browser, KOI:P2])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

6 years ago
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.
(Assignee)

Comment 1

6 years ago
This is intentional, in v1 you don't get to choose. This is likely to come later in v2.
(Reporter)

Comment 2

6 years ago
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.
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 ;)
Keywords: feature
Whiteboard: v2, interaction

Updated

6 years ago
Whiteboard: v2, interaction → v2, interaction, u=user c=browser s=v1.1-sprint-2
Whiteboard: v2, interaction, u=user c=browser s=v1.1-sprint-2 → v2, interaction, u=rmacdonald@mozilla.com c=browser s=v1.1-sprint-2
Whiteboard: v2, interaction, u=rmacdonald@mozilla.com c=browser s=v1.1-sprint-2 → v2, interaction
Depends on: 844285
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
(Reporter)

Comment 5

6 years ago
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?
(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.
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
(Assignee)

Comment 9

6 years ago
(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.
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?
Flags: needinfo?(bfrancis)
Duplicate of this bug: 849402
(Assignee)

Comment 12

6 years ago
(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
Flags: needinfo?(bfrancis)
Whiteboard: v2, interaction → v2, interaction, LOE:S
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

6 years ago
added an basic task in bug 856014 before saw this issue...
(Assignee)

Updated

6 years ago
Duplicate of this bug: 856014
Reposting the link to the spec as it appears to have been broken. 

https://www.dropbox.com/s/dkg6rjgmsq6jpwj/browser-defaultsearch.pdf
Could we at lease move the string to mozSettings first? That would at least make people who build Gaia easier to make the change.
(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

6 years ago
bug 840210 is tracked to patch apps/browser/js/init.json for build time customization
(Assignee)

Comment 20

6 years ago
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.
Flags: needinfo?(ffos-product)
Summary: No way to change search provider → Enable user to change default search provider in browser
Whiteboard: v2, interaction, LOE:S → v2, interaction, LOE:S c=browser u=user
(Assignee)

Updated

6 years ago
Whiteboard: v2, interaction, LOE:S c=browser u=user → interaction c=browser u=user
Priority: -- → P1

Comment 21

6 years ago
This is a valuable feature.  I will follow up with our partner teams to gather the right set of search providers.
Flags: needinfo?(ffos-product)

Comment 22

6 years ago
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.
(In reply to Robert Kaiser (:kairo@mozilla.com) [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.
(Assignee)

Comment 24

6 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) [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

5 years ago
(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.
(Assignee)

Updated

5 years ago
Assignee: nobody → bfrancis
(Assignee)

Comment 26

5 years ago
We can implement this without OpenSearch. This is really sprint ready though we could do with a list of search providers from Product.
No longer depends on: 883002
Keywords: productwanted
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.
(Assignee)

Updated

5 years ago
Duplicate of this bug: 889587
(Assignee)

Comment 29

5 years ago
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

5 years ago
(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.
(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.
(Assignee)

Comment 32

5 years ago
(In reply to Robert Kaiser (:kairo@mozilla.com) 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

5 years ago
A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/53548743
(Assignee)

Comment 34

5 years ago
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.
Flags: needinfo?(krudnitski)
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.
Flags: needinfo?(krudnitski) → needinfo?(blassey.bugs)
Flags: needinfo?(blassey.bugs)
Whiteboard: interaction c=browser u=user → interaction c=browser u=user [sprintready]
(Assignee)

Updated

5 years ago
Depends on: 840210
No longer depends on: 844285
(Assignee)

Comment 36

5 years ago
Created attachment 789768 [details] [diff] [review]
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.
Attachment #789768 - Flags: review?(dale)
(Assignee)

Comment 37

5 years ago
Created attachment 789776 [details] [diff] [review]
808732.diff

Oops. missed a string localisation. Sorry for the noise.
Attachment #789768 - Attachment is obsolete: true
Attachment #789768 - Flags: review?(dale)
Attachment #789776 - Flags: review?(dale)
(Assignee)

Comment 38

5 years ago
Created attachment 790377 [details] [diff] [review]
https://github.com/mozilla-b2g/gaia/pull/11534

Sent pull request
Attachment #789776 - Attachment is obsolete: true
Attachment #789776 - Flags: review?(dale)
Attachment #790377 - Flags: review?(dale)
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
Attachment #790377 - Flags: review?(dale) → review+
(Assignee)

Comment 40

5 years ago
Merged into master in https://github.com/mozilla-b2g/gaia/commit/f82d1454f03d930ae23c0cf00251ecf8d895330d
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
Duplicate of this bug: 904425
(Assignee)

Comment 42

5 years ago
Waiting for acceptance
Flags: needinfo?(krudnitski)
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?
Flags: needinfo?(krudnitski)
Flags: needinfo?(bfrancis)
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
Flags: needinfo?(ibarlow)
Flags: needinfo?(fdjabri)
(Assignee)

Comment 45

5 years ago
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.
Flags: needinfo?(bfrancis)
Thanks, Ben!
Flags: needinfo?(ibarlow)
Flags: needinfo?(fdjabri)
Whiteboard: interaction c=browser u=user [sprintready] → interaction c=browser u=user [sprintready] [UCID: Browser8, FT:Browser, KOI:P2]
Whiteboard: interaction c=browser u=user [sprintready] [UCID: Browser8, FT:Browser, KOI:P2] → interaction c=browser u=user [sprintready] [UCID:Browser8, FT:Browser, KOI:P2]
Forgot to mark this verified:
Gaia   73a64d360f0ed135fcca205c6292e9219e085413
SourceStamp e3c84e9f2490
BuildID 20131002040206
Version 27.0a1
Buri
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.