Status

()

Firefox for Android
General
P2
normal
RESOLVED WONTFIX
6 years ago
a year ago

People

(Reporter: elan, Assigned: bnicholson)

Tracking

({uiwanted})

unspecified
ARM
Android
uiwanted
Points:
---

Firefox Tracking Flags

(fennec11+)

Details

(Whiteboard: [QA+])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
* some fix up for the url handler - move handler from CLH into browser.js
* UI to allow user to change search provider (sqlite db)
(Reporter)

Updated

6 years ago
OS: Mac OS X → Android
Hardware: x86 → ARM
Priority: P1 → P2

Updated

6 years ago
Duplicate of this bug: 695193

Updated

6 years ago
Whiteboard: [QA+]
Assignee: nobody → madhava
Keywords: uiwanted
Given how we're scaling this back (from "pick from this list at search time" to "choose your default search provider"), this will go in Prefs.

Something along the lines of:

----------------------------
Search Engine           (v)
----------------------------

which, when tapped, gives you the list like so:


-----------------------------
| [icon] Google          [/]|
| [icon] Bing            [ ]|
| [icon] Yahoo           [ ]|

         etc.


Do we know what this full list is? Are we including Twitter and Yahoo?

Will we also include them all when we run out of awesomeresults in the awesomescreen?
(In reply to Madhava Enros [:madhava] from comment #2)
> Given how we're scaling this back (from "pick from this list at search time"
> to "choose your default search provider"), this will go in Prefs.
> 
> Something along the lines of:
> 
> ----------------------------
> Search Engine           (v)
> ----------------------------
> 
> which, when tapped, gives you the list like so:
> 
> 
> -----------------------------
> | [icon] Google          [/]|
> | [icon] Bing            [ ]|
> | [icon] Yahoo           [ ]|

This is the standard "list" preference in Android. We have built-in support for it. The only difference from the simple case is that we are building the list dynamically, not statically.

> Do we know what this full list is? Are we including Twitter and Yahoo?

The list will be whatever we support in XUL Fennec

> Will we also include them all when we run out of awesomeresults in the
> awesomescreen?

I don't think so. Not for v1 of the native UI
We can pull the list from the SearchService in browser.js

Let's just add messages to send the list to the Java layer. When setting the default via "Preferences:Set" we'll need to special case this preference and use the SearchService to set the default.
Assignee: madhava → bnicholson

Comment 5

6 years ago
Also, this list is locale dependent, and the data for that is currently in the gecko part, plus search plugins in the profile from user-installed searchplugins.

Comment 6

6 years ago
To clarify, I think that Madhava is wrong in comment 2 that we're adding an option for choosing ones "default" search provider. We're changing the "selected" one.

CCing Kev to keep him in the loop.
(Assignee)

Comment 7

6 years ago
From what it sounds like, you guys want to be able to switch the search engine from the preferences screen, with no search engine controls in the AwesomeBar.  With the current search service, that change would require modifying the "browser.search.defaultenginename" preference.

Pike, wesj, and I had a discussion about this in IRC:
http://pastebin.mozilla.org/1373839

Should we still go with this approach?
(Assignee)

Comment 8

6 years ago
Created attachment 572139 [details]
IRC discussion

included discussion as an attachment, just in case
(Assignee)

Comment 9

6 years ago
Created attachment 572173 [details] [diff] [review]
patch v1

Adds the Search Engine preference (currently ignored by the AwesomeBar).
Indeed, we created some confusion here. Let me restate the original goal:

* Typing two or more words in the awesomebar results in a Google search for those words.
* Let's make a preference to switch the search provider from Google (the default) to one of the other installed search engines.

So the assumption that the awesombar behavior was linked to the search engines was a bit wrong. nsIURIFixup uses the keyword.URL preference first, then tries to fallback to the default search provider, not the currently selected provider. We lose.

We either need to:
* Add specific code in browser.js to look for multiple words and manually use the selected search engine
* Add some UI to cause a search, not navigate
(Assignee)

Comment 11

6 years ago
Created attachment 573650 [details] [diff] [review]
patch v2

This patch now uses the selected search engine for searches.
Attachment #572173 - Attachment is obsolete: true
Attachment #573650 - Flags: review?(mark.finkle)
(Assignee)

Comment 12

6 years ago
Created attachment 573653 [details] [diff] [review]
patch for awesomescreen search UI

I think the "default search engine" option is a lot more sensible when we actually have a way to switch between them in the awesomebar UI.  This patch is one UI approach for doing so.

The search engine is shown at the top left next to the search bar, and the user can click and drag to select a different search engine.
Comment on attachment 573650 [details] [diff] [review]
patch v2

You shouldn't be modifying the browser.search.selectedEngine pref directly, it's managed by the search service. Use the Services.search.currentEngine setter/getter instead.
Attachment #573650 - Flags: feedback-
I think we have added search engine support everywhere we intend to for the initial Native release. If not, file a new bug with specs.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
tracking-fennec: --- → 11+
Attachment #573650 - Flags: review?(mark.finkle)
You need to log in before you can comment on or make changes to this bug.