(Note: this is filed as part of the “Paper Cut” bugs — we assume that there may be multiple existing bugs on this. Please make them block this bug, and we will de-dupe if they are indeed exactly the same. Thanks!) With the advent of browsers that only have one input bar that does both search and URLs,, enough people try to use URL bar as search, and are confused by the inconsistent behavior of the browse-by-name service Recommendation: Make it trigger a regular search instead of browse-by-name (current algorithms for detecting hostnames etc stay the same)
Limi: what sort of data do you have to back up the assertion? I think that when we get a direct URL result from a location bar query, we should have an override option (ie: an infobar or otherwise saying "This was the best result, but if you want to run a search, click here") but a lot of the time it nails it properly, so why do we want to insert the extra click?
A first time it gets the result wrong it will undermine the user's confidence that it will be correct in the future. Also, the user can't determine ahead of time what will happen when they input a term.
If it gets it wrong, they're one click away from a Google search. Not sure I'm understanding the "undermining" aspect here. The experience that I picture is: user types in hertz, hits enter - BBN takes user to hertz.com - infobar says "If this wasn't what you wanted, you can also _search Google for "hertz"_" - we prefetch that search page in the background so it's instantly available You're right that we should do some signaling to the user so that they know what to expect. Maybe we should actually do this the other way around, and if the BBN response sends a single entry, we can do a "did you mean" and by default show the search page? I guess I just don't like losing the "magic" aspect of this, and am slightly disappointed that the response to the problem reported in comment 0 is "remove BBN". Feels like this should really be about signaling what happens when a user enters text that isn't matched to anything else in the location bar.
If they want a google search, and we show them something that isn't a google search, we will frustrate them. Similar, if they wanted BBN, and we show them an info bar asking if we did the correct thing, the attention capture and slight time to read is also frustrating. Instead of posing a question after a non-deterministic behavior it is cleaner if the user knows ahead of time what will happen. For instance, if we always used I'm feeling lucky in the location bar, and google search results in the search bar, we wouldn't have to ask the user a question about if we did the right thing.
Beltzner: It violates the "least surprise" and "inconsistent behavior" principles — it behaves differently every time you use it. Sometimes you get a search result, sometimes you get a page — and sometimes you just get a timeout since the server in question isn't responding (which happened to me just five minutes ago :). This is really the kind of magic that I think only people that are intimately familiar with the browser really understand, and I understand the intent — but I think the downsides outweigh any upside. Of course we'll let you enable BBN if you really want it.
Keywords: ux-consistency, ux-mode-error
Also not as strong as a keyword, but the notification bar could violate ux-interruption if it was unprompted (the user was both anticipating and got BBN).
Added patch that changes the BBN search to a normal search instead. Note that this one has rls=org.mozilla:en-US:official, which is supposed to be only in the shipping products, not in the nightlies, as far as I understand it. I'll let others chime in on whether this is the best way to do it. Thanks to Frank Yan for finding the line to change. :)
Attachment #463324 - Flags: review?(dolske)
Also, I checked with legal (Harvey), and there shouldn't be any issues with changing this behavior.
Not sure that this blocks, but would take an approved patch.
blocking2.0: ? → -
Comment on attachment 463324 [details] [diff] [review] This changes the BBN search to a regular Google search Switching review to Gavin; I would have r+'d this myself, but wasn't sure if there was some pre-processor-fu we could add here to automate the generation of the search code parameters, as is done in the searchPlugin
Attachment #463324 - Flags: review?(dolske) → review?(gavin.sharp)
Comment on attachment 463324 [details] [diff] [review] This changes the BBN search to a regular Google search The addition of "rls" and "client" params has other implications (and likely isn't correct given the meaning of "firefox-a" in the search plugin URL). It isn't required for this bug - I think all you need to do is remove the "gfns" param. If we want to investigate making those additions for other reasons, we should probably do it in another bug.
Attachment #463324 - Flags: review?(gavin.sharp) → review-
Agreed; that's a better course of action. Fryn, shouldn't take you long to edit the patch for that, at which point I think you can assume an r+ from Gavin, and I'll a+ if you ping me :)
Comment on attachment 465417 [details] [diff] [review] patch v2 (simply change it to a regular google search) r+a=beltzner
Please be sure to file a followup bug for the searchcodes!
The second part of this was already filed as bug 586821.
Comment on attachment 465417 [details] [diff] [review] patch v2 (simply change it to a regular google search) http://hg.mozilla.org/mozilla-central/rev/d5e211bdd793
This won't work in l10n builds.
(In reply to comment #21) > This won't work in l10n builds. We realized that. How do we change this for other locales that also have keyword.URL set to Google search with gfns=1 (a "smart" decider between I'm Feeling Lucky and regular search) or something similar?
I'll make a patch against l10n-central to do this.
See Also: → bug 586821
This and bug 586821 try to touch the same thing, and should happen in one go, IMHO. Patching l10n-central doesn't help those localizations out there in the wild that are not in our HG repos, so that's really just false. I'm not sure why we need keyword.URL at all?
(In reply to comment #24) In that case, we can close this one and just finish up the work in that bug.
I think that this is the correct behavior, but, at least there should be an option that gives a clue to the user of this functionality. For example, when the user types anything without any prefixes like "http://", "www" or ".com" on the URL bar, then a tooltip as shown in the mockups: http://media.itsalltech.com/2010/04/panel-notification-win7-01.png should appear saying something like "Would you like activate browse-by-name feature?", then the user decides between activate or not. Who's agree?
I agree. Loads of people (in my experience) browse by name at least one or two sites. It will certainly confuse them when that suddenly goes away. Then again, if the browse by name feature can be activated by a doorhanger, an option in the preferences tab is in order. It's true that browse-by-name is inconsistent, but many people, like myself, have learned, over the years, to deal with that inconsistency, and use this function to great extents and that speeds their workflow by a LOT, and certainly makes stuff like the omnibar completely useless. So I think it's only natural to let those users keep browsing like they do.
Pretty quickly the awesome bar will associate the text they've entered with the result they want (which BBN does as well but in a global sense). So while there will be a momentary disruption in people's workflow's, the ultimate result is that they will have to hit the down arrow before enter in the future to get essentially the same functionality.
That's not new at all, so it "will" not, it just does already, and there's a reason those of use who do use BBN use BBN and not the down arrow thing. In any case, this is nowhere near relevant in broad terms. There will be a small wave of people asking about this at SUMO, but it's really a very minor change. A option to switch it on/off is the natural thing to expect. Also, these are the tow only queries I use for BBN: "list of series episodes" where series is the name of the series, like greys anatomy or something "youtube" I don't know if it's relevant, but that's what I use BBN for. I know my dad uses (or used) "gmail", so I'm thinking BBN is used mostly for a small amount of sites per user, and maybe a few quick queries that the users know will lead straight to a site, and not to a result page. Well, it **** me off when google sends me to a result page instead of a site, that's for sure. In any case, and again, I'm not arguing against removing BBN by default. It's really inconsistent. But, frankly, I'd be happier if all search queries on the location bar were to return an "I'm feeling lucky" result rather than a search page. That would be, in my opinion, the best approach, a clear differentiation between the location bar and the search bar, as it should be, and putting consistency and the location bar's behavior. In the end, as long as it's consistent, it's good design.
its a mistake, and I dont understand the reason for change. when I type bbc, yahoo news, bleacherreport, or wash post, what are the chances that Im not trying to goto bbc.co.uk, news.yahoo.com, or bleacherreport.com, or washingtonpost.com? It asks users to spend massive amount of time to do things that firefox has been doing for them. This regress firefox's awesome bar to the level of opera, safari, chrome and IE. so whats your advantages then? Confusing new users? why should 300m old users suffer for some new users that may never reach more than another 300 million? The whole thing is arbitrary, the problem is imaginary, and the solution will have backlash.
That's a bit of an extreme stance, to be brutally honest, but I can't say I don't understand where your coming from. I think the major thing to keep in mind is that this is a relatively minor feature that has an easy work around (the down arrow thing Alex talked about) and can be re-enabled with ease. It's not like tabs on title bar that break functionality ;) Ahahm, moving right along... Including a clear option to enable/disable this may be non-trivial (what with the localizations and customizations and all). Is there a way to make BBN off by default but detect if the users use it in old profiles? Maybe we could keep functionality for ported profiles and disable BBN for new ones? I don't know, I'm just saying...
Component: General → Location Bar
QA Contact: general → location.bar
There's no sensible preference for this, removing "by default" from the summary.
Summary: Disable browse-by-name by default → Disable browse-by-name
(In reply to comment #31) > the localizations and customizations and all). Is there a way to make BBN off > by default but detect if the users use it in old profiles? Maybe we could keep > functionality for ported profiles and disable BBN for new ones? I don't know, > I'm just saying... No, and I don't think it's worth it. The UX arguments for this change were carried out earlier in the bug, and do not need revisiting. Thanks for the input, but we're done here.
Oh, I missed those. Very sorry about that.
great that it is fixed. It seems to me that the ffx community is getting a bit conservative. If no change is ever possible because 'millions of users are used to it' or are 'used to work around it', no software will ever evolve. Thanks!
Sorry for the bump, but what ever happened to bug 233541 being verified WONTFIX? =/
(In reply to comment #38) I generally reluctantly agree with the notion of simplifying things for many users, but I would personally love to have a option for this, in GUI.
"Is anyone else having problems with the Awseome bar? If I type for an instance cnet news it won't get me to the site directly but instead to a google search." http://forums.mozillazine.org/viewtopic.php?p=9848891#p9848891 I probably should file a new bug asking to revert this change. I don't think there was a good enough reason to do this in the first place. BBN asserts that if you enter a distinct brand name, you very like don't want to do research on that brand but get to the official site. Without some kind of evidence that BBN actually misbehaved and made users sad, "If they want a google search, and we show them something that isn't a google search" is purely hypothetical and not convincing. At the same time it's not a feature I care about personally, which is why I haven't filed that bug yet.
I liked this feature a lot, but the "let's try not to confuse grandma" argument has some merit to it. Dão, if you have some good evidence in regards to this change being more of a problem than it was intended to fix, please file a new bug so we can discuss reverting this or at least adding an option. (I'd file, but I think you starting things would have more weight) The only way to change it back right now is to muck with a non-user-friendly URL in a hidden pref. FWIW, I have heard more than a handful of people say disabling BBN "ruins" Firefox for them. (their words, not mine)
A revert of the behaviour or an option would be very welcome. I field the 593686 bug. Really this options is why I use only the Awesome Bar to search and not the regular search field.
(In reply to comment #41) > I liked this feature a lot, but the "let's try not to confuse grandma" argument > has some merit to it. The point is that BBN didn't confuse grandma -- as far as I can tell. Anyway, we're slightly abusing bugzilla here, so I filed bug 593709.
For people who like the old behavior, here's a restartless add-on which brings browse by name back. <https://addons.mozilla.org/en-US/firefox/addon/222531/>
Filed bug 594515 for suggestion of built in option of some kind.
I agree disabling BBN by default, I disagree about not having an option to activate BBN (even in about:config)
(In reply to comment #47) > I agree disabling BBN by default, I disagree about not having an option to > activate BBN (even in about:config) Great, we have an option to activate it in about:config, so you don't need to be disappointed. Everyone wins, except for those still receiving email about this bug. The change is made, and we don't need additional opinions pro or con. Gracias, everyone.
Oh great - why have one search bar when you can have two search bars. I am sorry, but security reasons do not justify having two search bars. You want security - convert the patch into a security plug-in. It does not make any common-sense to have 2 search bars. "however apparently there were enough complaints of inconsistent/unexpected results" Really? I used to type firefox and it took me to mozilla firefox website - how unexpected is that? If people are worried about security then they should use and change the patch provided to disable BBN as a plug-in called awesomeBar security plugin. But no, instead a patch was created and then a plug-in to sit on top of it. YuS ~ Why go the long way when you can go the longer way? Just call Firefox 5 Mozzarella And no - it was never slow. ALl you had to do was type "bug mozilla", click enter, a wow you are directly in this site. Why can't there be an option in about:config so that people who know the "security risks" and are "confident" enough to use the "smart" bar (as some like to call it) for BBN? All it has to do is comment the patch provided!
(In reply to comment #49) > Why can't there be an option in about:config There is, as the previous comment stated, and is referred to in the link given in the URL field of this bug. I'll quote it here in case it is edited out in future: To use Google’s “Browse by Name” service, in about:config change the value of keyword.URL to http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=
(In reply to comment #50) > (In reply to comment #49) > > Why can't there be an option in about:config > There is, as the previous comment stated, and is referred to in the link > given in the URL field of this bug. I'll quote it here in case it is edited > out in future: > > To use Google’s “Browse by Name” service, in about:config change the value of > keyword.URL > to > http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q= Thank you for your clear response. I do not like the way the developers are handling the "new" changes, (Changing the way Firefox used to work, like BBN and Save and Quit when closing multiple tabs). The issue I have is that providing a plug-in/add-on for changing a single value in about:config is NOT the way to proceed. BBN confusion is not an appropriate excuse - as there is a search bar for "Searches". If security is a concern, then a add-on secure awesome bar needs to be implemented (i.e. the patch provided), for people who are worried about security. By providing add-ons for every change in behaviour, the developers are pushing users to look elsewhere. Which people will start doing, especially with comments in bugzilla stating that due to confusion the url bar does a search now, meaning there are two search bars. Well I still see the second search bar, at least remove it if the url is going to search anyway! No common-sense in the way that developers handles change, Chrome, Opera, YuS - there are other options, but I liked how firefox used to work. And no, I do not want an add-on that changes a single value in about:config Sorry but that is stupid, there is no other word for it. And, 2 search bars: Come on now that is pathetic, Point
@LW Your comments are just way of the mark. And it shows your knowledge about programming is, to put it mildly, insufficient. Stating that BBN always worked by giving some very simple examples of whén it worked is not so smart. Now, please stop whining and make the very simple change in keyword.URL or install: https://addons.mozilla.org/en-US/firefox/addon/enter-selects/ which makes it just as easy (after having visited the site once) and use search keywords for more advanced functionality (which simple users wouldn't have been using anyway, so they wouldn't have noticed this change in functionality). The awesome bar is really awesome in remembering and searching through your own history and limits directing to google search only when there's no ambiguity in what the users wants to do. This is the most secure option and the least privacy intrusive. That's why I use Firefox and not Chrome (which also adds search engines without asking).
You need to log in before you can comment on or make changes to this bug.