Closed Bug 695198 Opened 10 years ago Closed 10 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)
Assignee: nobody → madhava
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.
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.
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.
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?
included discussion as an attachment, just in case
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
This patch now uses the selected search engine for searches.
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
Closed: 10 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.