Closed Bug 593709 Opened 15 years ago Closed 15 years ago

Re-enable browse-by-name

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: dao, Unassigned)

References

Details

Bug 565966 disabled browse-by-name based on the idea that people "are confused by the inconsistent behavior of the browse-by-name service". Faaborg elaborated, "If they want a google search, and we show them something that isn't a google search, we will frustrate them". Now, BBN is based on the idea that people /do not/ want to search when entering distinct names. Rather than just assuming the opposite, we need to back this up somehow. In the meantime I suggest we back out the patch -- there are people who are confused by BBN not working anymore, that's for sure (http://forums.mozillazine.org/viewtopic.php?p=9841457#p9841457, http://forums.mozillazine.org/viewtopic.php?p=9848891#p9848891). (The other way of criticizing BBN would be to say that, while immediately going to the site is correct behavior for distinct names, google too often identifies not-quite-distinct names as distinct ones, leading to false positives. I don't know if this is an actual problem. If it were, the ideal solution would be to ask google to check if fine-tuning may be needed or to allow us to specify a custom threshold or something.)
Blocks: 565966
There's no need to duplicate the function of the Location bar and the search one.
In reply to comment #2: many used BBN instead of search because it's quick.
Actually, many used BBN instead of some bookmarks because it's quick, too.
Exactly instead of going to site's bookmark just type the name and one more useful feature was type a query for something and end it with wiki to open it in Wikipedia.
The problem with BBN is that it's slow, if there's a way to make it snappier then by all means, revisit the idea of turning it on, but in most cases, an accidental return will slow you right down.
(In reply to comment #6) > The problem with BBN is that it's slow, It's the first time I'm hearing this. This certainly wasn't the reason for bug 565966.
(In reply to comment #7) > (In reply to comment #6) > > The problem with BBN is that it's slow, > > It's the first time I'm hearing this. This certainly wasn't the reason for bug > 565966. No it wasn't. I agreed with the change but for different reasons. I just found BBN to be incredibly slow compared to searching from the locations bar "i.e. google [search term]". It felt somewhat like the browser would look up temporarily. That said, there's also a security risk with BBN. People should be encouraged to put in the full URL when browsing.
Requesting blocking on fixing this user experience regression. The loss of BBN forces users to develop new, possibly less efficient patterns. At this point it's entirely unclear how many users the alleged consistency win helps in return -- probably not many.
blocking2.0: --- → ?
Is there no way to get some numbers on this? Possibly a Test Pilot study?
There might be ways, but in the meantime we shouldn't arbitrarily break the behavior that a number of users depend on.
I think that at this point, where the request is to turn BBN back on, the onus should be on proving the demand/necessity for it. Especially considering other browsers do what the nightlies currently do and send users to search results.
(In reply to comment #12) > I think that at this point, where the request is to turn BBN back on, the onus > should be on proving the demand/necessity for it. The quantity may be unknown, but it's a fact that people got confused when BBN stopped working. Besides, you're right in that the status quo gets the benefit of the doubt. You're wrong because BBN being disabled isn't established as the status quo. For one thing, we haven't shipped this to end users yet. Secondly, the situation is that the reasoning in bug 565966 doesn't appear to be solid. The barrier for reverting unsound changes can't be higher than the barrier they had.
This is the first time I've heard of BBN being removed and I've happily used it since Firefox 1. Sure it makes for redundancy with the Search Bar being available, but BBN is faster. And if BBN doesn't turn up something I'm looking for, then I turn to the Search Bar or fine-tune my search query. I would be fine with BBN being removed if the Location and Search Bars could be combined, but I'd settle for an about:config preference to turn BBN on/off as long as BBN isn't gone for good (i.e. it's removal was by design). I'm just tossing out some ideas/suggestions. I hope they can help somewhat.
I agree with Browse-by-name being removed by default for all the reasons given in bug 565966 especially the point about security - users must be aware of the URL that they are being redirected to. But there needs to be a replacement. e.g. add the top search result in Google (or the current search engine) high up in the Awesome Bar results in the same way that matching tabs are now listed. Is Bugzilla is the place to discuss this?
(In reply to comment #16) > I agree with Browse-by-name being removed by default for all the reasons given > in bug 565966 especially the point about security - users must be aware of the > URL that they are being redirected to. Security concerns haven't been part of bug 565966. > But there needs to be a replacement. e.g. add the top search result in Google > (or the current search engine) high up in the Awesome Bar results in the same > way that matching tabs are now listed. Is Bugzilla is the place to discuss > this? No, the newsgroups are, unless you have a concrete enhancement request, which you should file as a separate bug.
(In reply to comment #17) > Security concerns haven't been part of bug 565966. excuse me I typed in haste - I meant to add that there is another issue about security - users must be aware of the URL that they are being redirected to.
Sure, let's not turn this into a "things I like or dislike about BBN" thread, though.
I do not believe that shipping Firefox 4 without this fix would make the product significantly worse. Yes, people might need to develop new habits, but that argument can easily be made against just about any UI change. FWIW, it should be pretty easy to write an add-on that restores this feature.
blocking2.0: ? → -
(In reply to comment #20) > FWIW, it should be pretty easy to write an add-on that restores this feature. (Indeed. Restartless, even - https://addons.mozilla.org/en-US/firefox/addon/222531/ )
(In reply to comment #21) > (In reply to comment #20) > > > FWIW, it should be pretty easy to write an add-on that restores this feature. > > (Indeed. Restartless, even - > https://addons.mozilla.org/en-US/firefox/addon/222531/ ) Thanks to Ehsan Akhgari for writing that and all, but how did an extension to alter one pref end up being 129KB? Is the JetPack SDK that inefficient?
Yes but how many people that depend on this way to search will know for what addon to search exactly and if ever try searching for addon.
I think at a minimum this debate should result in a built in option in the GUI somewhere to decide if you want BBN on or not, possibly just off by default.
For the those who aren't already aware, BBN being on or off is not a boolean switch. It's a matter of setting your "keyword.URL" pref in about:config to: BBN on: http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q= BBN off: http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&q= There is no simple option currently, even in about:config.
I suggest that we document clearly how to get BBN back (and I did ask the SUMO team to make sure this happens) — and you should use the add-on at https://addons.mozilla.org/en-US/firefox/addon/222531/ if you are unwilling to change about:config manually.
A previously established habit forming simple feature like this should just have an option built in. I think an addon is the wrong way to go. I think a built in GUI option is required, or at least a simpler way to toggle via about:config.
Filed bug 594515 for suggestion of built in option of some kind.
Blocks: 594515
(In reply to comment #20) > I do not believe that shipping Firefox 4 without this fix would make the > product significantly worse. Care to justify your belief? I think the reasoning in comment 0 deserves a more substantial reply than a statement of belief - ideally from the people that made the call in the first place (faaborg/limi/beltzner?). (Side note: Restoring the BBN behavior would likely require either reverting bug 586821, or finding some work around - either something like bug 587780, or something hackier.)
blocking2.0: - → ?
(In reply to comment #0) > Bug 565966 disabled browse-by-name based on the idea that people "are confused > by the inconsistent behavior of the browse-by-name service". Faaborg Actually, the crux of the argument was in bug 565966 comment 6 - and I was forced to agree. Consistent behaviour should trump, even in cases where we're trying to do things that are "magic." A user must be able to rely on their tools, and sadly, the BBN algorithm leads to inconsistent results* Further, the bug was filed based on feedback from a survey of users (conducted on reddit, a primarily technical audience) which indicated that the lack of consistency (as well as the speed of BBN) was seen as a popular problem with the smart location bar. > elaborated, "If they want a google search, and we show them something that > isn't a google search, we will frustrate them". Now, BBN is based on the idea > that people /do not/ want to search when entering distinct names. Rather than > just assuming the opposite, we need to back this up somehow. In the meantime I The system here has worked, though it's good of you to check. The initial impetus came from user feedback, a discussion was held in bug 565966, a proposal was made by the UX team and approved by the nominal product driver for Firefox, me. Yes, other user focus groups and surveys could indeed by conducted, but I fear they'd end up being no more scientific (having run a bunch of these, you'll just have to trust me) as the techhie-skewed reddit survey that garnered hundreds of datum. > suggest we back out the patch -- there are people who are confused by BBN not > working anymore, that's for sure > (http://forums.mozillazine.org/viewtopic.php?p=9841457#p9841457, > http://forums.mozillazine.org/viewtopic.php?p=9848891#p9848891). UI change will confuse some people, yes. That's inevitable. It does not mean, however, that we cannot or should not change our UI, nor does it mean that every UI change requires a preference to revert to old behaviour. Welcome to the wonders of mature software! This is not a blocker, and I am resolving it as WONTFIX. * yes, technically, the results are consistent: it does a BBN search, which will provide a direct website in cases where the search engine confidence is high, and a search page in all other cases. That behaviour is consistent if you know about it, but few people do, and it's hard to predict. (Full disclosure: I've reverted the pref locally, and prefer using BBN. I do fear, however, when I first proposed that change for Firefox 2, I let my personal biases for the feature trump the principle of consistent user experience.)
Status: NEW → RESOLVED
blocking2.0: ? → -
Closed: 15 years ago
Resolution: --- → WONTFIX
In hopes that this comment will prevent people from turning this bug into a battlefield, try this extension to bring back the functionality: <https://addons.mozilla.org/addon/222531/>
The newer 1.1 version (not default yet on AMO) is only 1 KB: https://addons.mozilla.org/addon/222531/versions/?page=1#version-1.1
(In reply to comment #32) > The newer 1.1 version (not default yet on AMO) is only 1 KB: It won't take long to be the default, that version is public (as opposed to being in the sandbox)
(In reply to comment #31) > In hopes that this comment will prevent people from turning this bug into a > battlefield, try this extension to bring back the functionality: > <https://addons.mozilla.org/addon/222531/> The pref is locale specific, no? So that add-on won't quite do the trick.
(In reply to comment #30) > Further, the bug was filed based on feedback from a survey of users (conducted > on reddit, a primarily technical audience) which indicated that the lack of > consistency (as well as the speed of BBN) was seen as a popular problem with > the smart location bar. Good. This should have been mentioned in the bug.
(In reply to comment #34) > (In reply to comment #31) > > In hopes that this comment will prevent people from turning this bug into a > > battlefield, try this extension to bring back the functionality: > > <https://addons.mozilla.org/addon/222531/> > > The pref is locale specific, no? So that add-on won't quite do the trick. Hmm, how can I solve that problem?
(In reply to comment #36) > Hmm, how can I solve that problem? Maybe get the preference, and then just append that last little bit?
(In reply to comment #37) > (In reply to comment #36) > > Hmm, how can I solve that problem? > Maybe get the preference, and then just append that last little bit? But the current value of the preference would be empty. Also, doesn't Google choose the locale based on GeoIP data?
The old pref did not vary based on locale. Locale detection was entirely handled on Google's side, and should continue to be for users of Ehsan's jetpack (assuming he used the same URL...).
It actually varies, but not much. I would also expect locales to pick different services according to their default search engine, but apparently they haven't got around to it yet or those engines don't support it.
(In reply to comment #39) > The old pref did not vary based on locale. Locale detection was entirely > handled on Google's side, and should continue to be for users of Ehsan's > jetpack (assuming he used the same URL...). I did.
Oh, yeah, I forgot about those variances. They're mostly unintentional. The only locale that ships a non-Google default engine is ru, and it uses yandex for keyword.url.
Oh great - why have one search bar when you can have two search bars. I am sorry, but security reasons and stupidity 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.
You need to log in before you can comment on or make changes to this bug.