User Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0a1) Gecko/20120122 Firefox/12.0a1 Build ID: 20120122031050 Steps to reproduce: Bug "Enable inline autocomplete again, but make it smarter" - https://bugzilla.mozilla.org/show_bug.cgi?id=566489 - has actually made the Awesomebar much, much dumber. Example: I type 'news' in the Awesomebar 1. before bug 566489 this would have given me http://www.guardian.co.uk/ (because it matches on "Latest *news*, sport and comment from the Guardian") as first result because I've visited that URL over 500 times 2. after bug 566489 I am offered http://newsandstar.co.uk/ which I have visited ZERO times (but have visited a page on that domain ONCE) This is a regression in usability for me. Before I could just type and enter. Now I must type, focus on Awesomebar, choose URL, cursor and enter. NOTE: I use https://addons.mozilla.org/en-Us/firefox/addon/enter-selects/ which gave me perfect functionality before 566489 - just type and enter. This should be default behaviour IMO.

AIUI, Chrome gets around this problem by only inline-autocompleting URIs you've explicitly typed before.

NOTABUG. If you want to open The Guardian, type guardian

(In reply to Péter Varga from comment #2) > NOTABUG. If you want to open The Guardian, type guardian With that logic you might as well argue we should just type out every URL in full. Even if you do not, many people access URLs by keyword - such as 'news' or 'weather' or 'sport' - and bug 566489 has broken that functionality unless the domain happens to begin with that keyword or there is no domain that begins with that keyword in which case the user might get lucky. Try and imagine that not everyone uses Firefox the way you do. The Awesomebar should be smart and offer the user what they want. Very obviously if someone has accessed a URL 500 times using 'news' then he does not want the first result to be a URL that he has NEVER visited. ITSABUG.

I agree this new behavior is perturbing. But I don't see any better way to enable inline autocomplete. You can't show the first result of the awesomebar (type "news", it can't be replaced by the "guardian.co.uk"). > This is a regression in usability for me. Before I could just type and enter. Now I must type, focus on Awesomebar, choose URL, cursor and enter. Not arguing on the "regression in usability", but this new behavior doesn't bring any extra steps in selecting the first result. With or without this feature, you'll have to type, select first result, then hit enter. "Before I could just type and enter" <- this is not true afaik.

(Note: I don't use Firefox. Exactly because of the bug that bug 566489 solves)

(In reply to Paul Rouget [:paul] from comment #4) > "Before I could just type and enter" <- this is not true afaik. DavidC indicated that he is using the "Enter Selects" extension which always selects the first entry from the result set. I've been using aforementioned extension as well for a long time now and I expected that inline autocomplete would simply integrate this functionality into Firefox proper. I know that evangelism is usually not welcome in bug reports for obvious reason but I do have the strong urge to mention that I find it highly unsettling that Mozilla might break/dumb down one of Firefox' last features which really sets it apart from its competitors.

Okay, let me elaborate. The ICANN has recently announced that new top-level domains will be available. If a company happens to have a lot of money, they can buy their own TLD. I think Google will do so. Now, let's just imagine news corp will also do it. Then, http://news/ will be their homepage. In that case, Firefox users won't be able to open it (with a similar pervious browsing history to you)

> But I don't see any better way to enable inline autocomplete. I guess I'm arguing that bug 566489 is fundamentally flawed. I would vote for it to be backed out. I want the Awesomebar to give me a URL based on either the content of URL string or <TITLE> string, depending on the frequency that I use either. For me, it was perfect before. This patch does not seem to be a win for me in any situation. Looking at the tale end of the comments for 566489, I'm clearly not alone. And I'd bet that a significant percentage of users use it the same way. There are plenty of sites that we access by a word that is not in the URL: Amazon.com = 'shop'; we7.com = 'music'; etc. etc. Or how about people who bookmark + tag a URL and want it to appear when they type the tag word in? > this new behavior doesn't bring any extra steps in selecting the first result. But it does when the first result is some URL I've never visited if only because it's that momentary "WTF?!" feeling as you're presented with a URL you never or very rarely visit in place of a URL you visit regularly and expect to appear. I think this change will cause a lot of pain for users if it makes out to release. > "Before I could just type and enter" <- this is not true afaik. Sorry, it does for me - I've confused the issue a little by describing my setup. See note I added to bottom of bug report: "I use https://addons.mozilla.org/en-Us/firefox/addon/enter-selects/ which gave me perfect functionality before 566489 - just type and enter. This should be default behaviour IMO." That is now broken. I guess I should raise another bug for that.

(In reply to Péter Varga from comment #7) > news corp will also do it. Then, http://news/ will be their homepage. I don't think that is right. It would be e.g. http://fox.news or http://bbc.news depending on who bought it. Either way, Awesomebar should match on frequency of accessing a URL by keyword that appears in URL or <TITLE> or tags. Anything from News Corp would be close to zero for me so it would not appear if I typed in 'news'.

It sounds like the enter-selects extension needs to be updated to override/disable inline-autocomplete. Note that we considered and rejected enter-selects-type functionality in bug 566489. But we can't do full awesomebar lookups fast enough to keep up with typing, so there was no way to make it work well. (Note that Chrome's awesomebar is intentionally dumber than Firefox's awesomebar to allow fast synchronous lookups. It's a tradeoff.) You'll get a lot more traction in this bug if you come up with a concrete suggestion for how inline-autocomplete can be improved. Saying that you want it backed out because you don't like it probably won't get much traction; the decision was already made to put it in. I'm going to file a separate bug on making inline-autocomplete only complete URLs you've typed.

(In reply to Justin Lebar [:jlebar] from comment #10) > Saying that you want it backed out because you don't like it... That completely ignores everything that I have written that explains why I believe it will be bad for lots of users. As Erunno @ comment 6 says, this is "dumbing down one of Firefox' last features which really sets it apart from its competitors." The Awesomebar was actually awesome in comparison to Chrome's address bar - it learned where I (i.e. the USER) wanted to go. Now they are similarly dumb.

I'm sorry, David. I didn't mean to imply that you haven't backed up your claim that this change is harmful, or that your arguments are somehow invalid. In fact, I agree that the situation you describe in comment 0 is problematic. But what I was trying to say is, every time we change the UI, the change is better for some people and worse for others. See for example getting rid of the status bar, tabs on top, the awesomebar... (*) As a result, the FF UI team in particular has, out of necessity, something of a thick skin. They decided long ago that inline-autocomplete is, in principal, a good thing, and it's unlikely that you're going to convince them in this bug that inline-autocomplete should be abandoned because there's no way to make it a net-positive feature. Again, I don't mean to imply that you're arguing for abandoning this feature; I'm just saying you're likely to be disappointed if you do argue for abandonment. Thus my suggestion that, if you'd like to see something happen as a result of this bug, you should consider whether inline-autocomplete can somehow be improved to your satisfaction, within the technical limitations we face (**). Maybe your answer is that it can't be! That's fine too. I just wouldn't get my hopes up, in that case. (*) Funny story: The guy who had exclusive UI review power over all of Firefox up until a few months before tabs-on-top landed was strongly opposed to tabs-on-top. And yet here we are. (**) For example, my understanding is we technically can't implement something like enter-selects-the-first-item-in-awesomebar, as explained in comment 10.

there is some reasons that make me thing this is only partially valid: 1. From what I read you had a keyword, and it doesn't work anymore, this is bug 720110, it's a bug that should be fixed, not much related to inline if not that it caused it 2. this version of inline is not supposed to return the first entry in the popup, for how bad that may be, there's no way to do that. There's likely way to improve the results though! 3. As paul said, inline autocompleting "news" to "somethingelse.com" is never going to happen, we don't want to change what you typed 4. As already said the extension you are using is likely needing an update, but in the meanwhile you can just disable the new autofill with browser.urlbar.autoFill pref 5. True, whatever change we make someone will like it someone will not. Though the right approach with your dislike is not asking to drop the feature whether figure out how it may be improved to satisfy you Btw, be sure nobody has anything against you or your ideas, we try to do our best to satisfy users requests, as far as possible.

Yeah, this is working as intended (modulo some bugs, as Marco pointed out). If you don't like the way it works, I'm sure there are extensions that can adjust the behavior, or you can just turn it off altogether. The goal of the feature is to make the people that "speak URLs" as fast as the people that "speak web page titles", and that's what this feature does. If you want awesomebar completion, you use the down arrow like before.