When typing a word in the location bar (versus url), Firefox should take user to the "right" web site, e.g. typing in "Ford" should take you to "http://www.fordvehicles.com/". All logic is handled by the keyword search provider (in this case Google's I'm Feeling Lucky search service). This doesn't work 100% of the time and we should notify the user what's going on when a user is taken to a "wrong" web site. This could be handled on the server-side as well but would need to work with keyword search provider to define what that experience should look like.

See also related bug 263213 and bug 275957.

Or for that matter bug 258838, which was the reasonable solution: if the keyword resolver is sure, go there, if not go to search results. If G wants to refine the quality of their certainty, click-tracking on the results pages served to a few million Firefox users ought to help. I'm not sure what sort of thing would get us fordvehicles.com, though, since ford.com is the number one result for every single search engine.

And how, exactly, do you figure we'll determine what the wrong site is if the site is absolutely sure? Browse by Name is pretty conservative, but maybe that's the right thing at this stage? Needs some more extension consideration, plussing so it stays on radar to look at for alpha2.

Either using BBN or fixing bug 275957 seems like the right way to go here.

-> beltzner, need to figure out some non-technical implications, changing to BBN is trivial (change keyword.URL to http://www.google.com/search?ie=UTF-8&sourceid=navclient&gfns=1&q= to test)

So here's what I recommend ..: 1. We switch keyword.URL to use BBN 2. If BBN returns a hostname, we navigate to that hostname 3. If BBN doesn't return a hostname, we navigate to the results page from a search query using the currently selected search engine. As an option, we could ..: 2a. If BBN returns a hostname, we navigate to that hostname and pop a notification message that says: | %prod; thinks this is the page you were looking for. | | If it isn't, you can search for %s. ( Search Now ) | where clicking ( Search Now ) would pass the content of the URL bar to the currently-selected search engine. Objections? (As a fallback position, we can just change keyword.URL to BBN, which over the past week has returned exactly what I was looking for about 80% of the time. As a bonus, I think I can even make that patch!)

What I was thinking originally was: 1) BBN 2) If no good match then an info bar message that said more eloquently than this, "We couldn't find an exact match for 'foo'. Here are the search results for 'foo'" It's possible that the second message could be passed through by the BBN provider. I don't know if I like that experience though. -- I think I prefer the fall back of using a better keyword.url service like BBN (I'm assuming it is), but introducing the feature when it first happens via an infobar message or even a full text tab page introduction in the background. Or something else to introduce the feature. I don't like having two different experiences of displaying our best guess or a search results page. It should be consistently one or the other.

(In reply to comment #7) > 2) If no good match then an info bar message that said more eloquently than > this, "We couldn't find an exact match for 'foo'. Here are the search results > for 'foo'" It's possible that the second message could be passed through by > the BBN provider. Yeah, I went the other way, since really, BBN is the guess. Performing a search when a user enters a string that isn't a URL is, I would think, the safest course of action and the one a lot of users would expect. Guessing at the domain name is the action that's nice if we get it right, but annoying if we get it wrong, so I want users to be able to quickly get to a search if the BBN assertion wasn't what they were looking for. > I think I prefer the fall back of using a better keyword.url service like BBN > (I'm assuming it is), but introducing the feature when it first happens via an > infobar message or even a full text tab page introduction in the background. > Or something else to introduce the feature. I think we get that with the infobar I've proposed. If we don't assume a site, we give the user a search. If we do assume the site, we tell the user we've done that and offer to do a search. > search results page. It should be consistently one or the other. I disagree. It should be what we think best accomplishes the user's intended task. If we have an educated guess, we should take it and leave an option for a search. If not, we should just present a search.

A few more random thoughts: - The safest implementations would be a)swap out w/ BBN service, b) do nothing or swap out w/ BBN and explain the experience on first or every use. - I'm not sure what the expectation is when typing in text that's not a domain. The 50+ MM current Firefox users may or may not expect (or like) the current experience. IE users converting to Firefox would expect to see search results though. - Consider that if you do want to do the keyword provider for domain match w/ the default search engine as the fall back search, there's extra logic/potential latency there. It might be better for the BBN provider to also provide the fall back search result. Also think that if the default search engine is Amazon, this whole experience would be pretty strange and would look like Firefox got hijacked. - I'm not understanding how you're able to determine what the user is intending based on what their input it unless it's explicit e.g. typing in www. .com or typing a keyword plus term. If a user types in text, it's hard to say where they want to go, whether to a domain directly or to a search results page. E.g. if I type in "Oakland as" I'd want to go to the oakland a's web site directly (which has the crappy domain of oakland.athletics.mlb.com).

(In reply to comment #9) > A few more random thoughts: > - The safest implementations would be a)swap out w/ BBN service, b) do nothing > or swap out w/ BBN and explain the experience on first or every use. Define "safest", please? As I've explained, the proposed mechanism clearly explains what is happening at every stage of the interaction. If we can't make an assumption, we run a search. If we can, we indicate what we've done. I don't think we should rely on first-exposure dialogs, since they're both sloppy UI which tends to not get read by users, and they assume that you've got a one-user-per-machine situation, which is often not the case. When they're not part of the first-run experience, I'm pretty dead-set against them. > - I'm not sure what the expectation is when typing in text that's not a Right now I think there's no real expectation other than search. We can do better than search, though. BBN is pretty damned great, really, and when it fails, we can pass off to search. > - Consider that if you do want to do the keyword provider for domain match w/ > the default search engine as the fall back search, there's extra > logic/potential latency there. It might be better for the BBN provider to It might be, that's true, but I think it's easier to understand why the product would have searched with your selected search engine than with one that wasn't selected. We would have to copy the search term into the search bar, though. > E.g. if I type in "Oakland as" I'd want to go to the oakland a's web site > directly (which has the crappy domain of oakland.athletics.mlb.com). Yeah, and BBN gets you there, fwiw.

I'm using your definition of safest to mean what users would expect in your previous comment. Anyhow, the proposal looks good except using the selected search engine as the fall back from BBN concerns me. It works if Google, Yahoo or another "navigational search" engine is selected, but it's a pretty bad experience if ebay, Amazon or someone else is there. I'm concerned about the latency too but mostly not expecting that the search bar default choice also alters the url bar experience. I guess I'd like to see whoever the BBN provider is to provide the fallback search too. I understand the sensitivites around this but I think it's all one service. Another option to consider probably not in time for Firefox 2 is for Mozilla to own/develop the default keyword service experience on the server side (which would mean a Mozilla branded fallback search). Just another option, but fairly clean from my perspective anyway.

pushing out non-critical-path bugs to b2

Phil: again, is this the sort of thing we'll need to have localized? Or since we're just talking about keyword searches, do we not need to worry as much?

-> beltzner, to get a plan for what changes we need to do here.

(In reply to comment #13) > Phil: again, is this the sort of thing we'll need to have localized? Or since > we're just talking about keyword searches, do we not need to worry as much? My vote, given the apparently tiny number of searches this represents, is that it would be nice to have but not a blocker. Even if it doesn't get localized for 2.0, I'm led to believe that google will use the proper locale based on accept-languages, as long as we leave off the language url parameter (as was decided for 343849). That's not as perfect as giving locales a choice of keyword search provider, but it's far from disastrous.

I spoke with Chris Beard, and here's the final decision of what to do: - keyword search should be tied to the default search provider - when default search provider is Google, we use Google's BBN - when default search provider is Yahoo!, we use Yahoo!'s normal query string - we are not to use the same search strings as are used by the searchbox. - tracking codes would be nice just for keeping stats on how often keyword search is used, but not a priority. - the design in comment 6 is a nice-to-have, but can be done in a followup bug for a subsequent release Patch coming up.

Axel: we'll need you to cover off associating this with the appropriate search providers in the appropriate locales. Brian: is there a tracking code we should be adding to this URL? no big deal if we can't get it, but it might be nice for analytics (see comment 16)

00:57 <@Baz> oe=UTF-8 (for output encoding) and rls=org.mozilla:en-US:official Am I missing anything else?

Comment on attachment 230694 [details] [diff] [review] changes en-US keyword.URL to use Google's browse by name r=me with beltzner's additions in the previous comment

carrying over r=mconnor from previous We decided not to use the tracking string for now since it contains the code for official releases and we're gonna land this on trunk which isn't an official release. If we want it in branch we can land it there as we check in.

Comment on attachment 230846 [details] [diff] [review] adds oe=UTF-8 but not the tracking string (whoops! self-review is so declasse!)

(In reply to comment #18) > Brian: is there a tracking code we should be adding to this URL? no big deal if > we can't get it, but it might be nice for analytics (see comment 16) From Google's perspective, it would be good to change the param to rls=org.mozilla.urlbar:en-US:official so we can distinguish it from other searches. Not a super-high priority though.

(In reply to comment #23) > From Google's perspective, it would be good to change the param to > rls=org.mozilla.urlbar:en-US:official so we can distinguish it from other > searches. Not a super-high priority though. The rls param's value has had a specific composition since it was created: MOZ_DISTRIBUTION_ID:LOCALE:ISOFFICIAL. All of the params are specific to a given build, and shouldn't change depending on use (location bar vs. search bar). If there is a need to track those two uses seperately, a new parameter should be used.

mozilla/browser/locales/en-US/chrome/browser-region/region.properties 1.18

(In reply to comment #18) > Axel: we'll need you to cover off associating this with the appropriate search > providers in the appropriate locales. This is either Phil or Mic, I guess Phil.

> > Axel: we'll need you to cover off associating this with the appropriate search > > providers in the appropriate locales. > > This is either Phil or Mic, I guess Phil. Axel: I'd like you to take care of this, please, since you know your way around the tree. The l10n doc includes a section about which search provider is default for a given locale (http://wiki.mozilla.org/Firefox2/L10n_Requirements#Search_Plugins) I also added a section today about the specific URL format for Yahoo searches, but it should be the same as was used in 1.5. Thanks!

If you're looking for some sort of notification, you might want to look at the Google Toolbar BBN notification given in IE: http://www.squarefree.com/browse-by-name.png

Comment on attachment 230846 [details] [diff] [review] adds oe=UTF-8 but not the tracking string we'll deal with the tracking bit in a followup

carrying over a+ and r+ from previous patch, just unbitrotting

Please see bug 354655

V/fixed. I see the changes in lxr, and also checked using: Build identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a7pre) Gecko/200707070404 Minefield/3.0a7pre In case you are wondering how we ended up w/ "I got lucky" a long time ago, see Bug 172389. I am somewhat curious if people think having this on by default is still needed now that firefox has the new-improved search field (which I believe is what the "BBN" comments refer to...). This is off in Seamonkey and Camino, by default.

I have no idea why this already fixed bug was nominated for a bunch of things, but clearing all those flags...