User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141013200257 Steps to reproduce: Enter hostname without domain and "http://" into location bar, e.g. "cam" instead of "http://cam.domain.local" Actual results: FF went to Google search with the hostname as keyword Expected results: FF should have first tried to find a matching host. This behavior changed with the update to 33. Before, FF would first try to find a host with the respective name in the system's search domains and only if a host wasn't found go to an external search engine. This is excessively annoying and has a major impact on usability and productivity in intranet environments! Additionally, it is potentially privacy- and security-relevant as it reveals local hostnames to the search engines which are proven to routinely collect personal data and violate privacy.

This is an intentional change. Prepend http:// to avoid the search. This is mentioned in the release notes. https://www.mozilla.org/en-US/firefox/33.0/releasenotes/

The change is BAD and the implementation is BAD. Even when adding "http://" while entering, the "http://" will be gone after hitting enter, means, if you want to append anything to the current address, say, some parameter, you have to edit the whole location bar line and also prepend "http://" AGAIN! Either make the behavior consistent and logical or offer an option to completely deactivate search from the location bar! Search from the location bar is anyways completely redundant with the search field right next to the location bar. The current behavior is inconsistent, illogical and cumbersome for everybody in an intranet enviroment as well as anybody doing any kind of web-development which requires frequent changes or the URL e.g. for testing parameters. The high potential for accidentally leaking URL parameters by triggering a search are a serious privacy and security concern which actually would warrant a security warning and recommendation to not use Firefox!

After the first search, and clicking the button to go to the domain you wanted, the same should not happen again for that same domain. Is that not what you're seeing? (you can manually edit this whitelist in about:config, too, so your intranet admins could fix this if they do a common distribution / default profile)

No, even if the URL is in the drop-down history list of the location bar, it will trigger a search! Examples: Enter "http://intranet/xml/phonebook.php" Hit enter Got to the location bar, append "?letter=a" => Goes to search! Got to the location bar, append "?letter=a" and prepend "http://" AGAIN => does not go to search Go to arbitrary website After that, go to location bar and type "intra" In the dropdown-list select "intranet/xml/phonebook.php?letter=a" and hit enter => Goes to search AGAIN, including the parameters in the URL!

(In reply to Stefan Gofferje from comment #4) > No, even if the URL is in the drop-down history list of the location bar, it > will trigger a search! > > Examples: > > Enter "http://intranet/xml/phonebook.php" > Hit enter > Got to the location bar, append "?letter=a" > => Goes to search! > Got to the location bar, append "?letter=a" and prepend "http://" AGAIN > => does not go to search > > Go to arbitrary website > After that, go to location bar and type "intra" > In the dropdown-list select "intranet/xml/phonebook.php?letter=a" and hit > enter > => Goes to search AGAIN, including the parameters in the URL! I can't reproduce any of these, and this is a different issue from the one in comment #0, which was about the infobar when typing a host into the location bar. Can you try a clean profile and/or Firefox's safe mode ( https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles and https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode ) ? Are there spaces in the URLs you're using in the dropdown test? (cf. pre-existing bug 690307) Besides, you didn't answer my question: you should get an infobar with the search . If you click "Yes, take me to <intranet>", does the same thing happen again?

With a clean profile in a freshly set up VM, things work as you described. However, on my desktop which is not fresh and clean I see the described problems. On my own desktop, I see an infobar but the search is triggered BEFORE the question is asked! That could already leak information to search engines. That question should be asked before the search is triggered. Also, the infobar is almost camoflage in color. Considering the potential security/privacy impact, it should be red or at least yellow and more than 12 or 16px high. From a privacy/security point of view, Firefox should treat ALL "old" entries in the location bar history as URLs and NONE as keywords! ESPECIALLY after an update when this search function was newly introduced. The probability is quite high that the location bar history contains URLs with session keys or other sensitive parameters which are leaked to the search engine when a search is triggered. Also, take into account that a browser update is an automatic function on most OS, so you cannot assume that the normal user is aware of that change in behavior. The developers have created a major security and privacy issue here! I have found that the whole location bar search can be switched off by setting keyword.enable to false. You might want to put this into the preferences dialog somehow.

(In reply to Stefan Gofferje from comment #6) > With a clean profile in a freshly set up VM, things work as you described. > However, on my desktop which is not fresh and clean I see the described > problems. On my own desktop, I see an infobar but the search is triggered > BEFORE the question is asked! That could already leak information to search > engines. That question should be asked before the search is triggered. This isn't possible, because the "whole point" of this change is to avoid the multiple-seconds wait that DNS queries involve for things that in 99.99% of cases aren't meant to be hostnames in the first place. In any case, as soon as a host is added to the whitelist (which the button on the infobar will do), we will no longer do a search query. > From a privacy/security point of view, Firefox should treat ALL "old" > entries in the location bar history as URLs and NONE as keywords! ESPECIALLY > after an update when this search function was newly introduced. The > probability is quite high that the location bar history contains URLs with > session keys or other sensitive parameters which are leaked to the search > engine when a search is triggered. I agree here, but as I said before, we need some steps to reproduce. Any idea what's different with your existing profile compared to the new one? Have you tried disabling all your add-ons and/or restarting in Firefox's Safe Mode (Help > Restart with add-ons disabled)? Have you checked any prefs you've toggled? Have you finally clicked the "Yes, take me to X" button and did that help? Is there or is there not whitespace in the URLs this happens with? If we don't understand the problem, we can't fix it. Going back to the previous behaviour wholesale is not an option. I'd love to fix this situation for you (I implemented the current situation!), but, with all due respect, I'm going to need more answers instead of complaining about different things in each comment. > Also, take into account that a browser update is an automatic function on > most OS, so you cannot assume that the normal user is aware of that change > in behavior. The change should be almost strictly positive. The fact that the dropdown selection seems to be breaking for you is a bug, which we should fix assuming it isn't caused by an add-on or other things. > The developers have created a major security and privacy issue here! I strongly disagree. This falls under "this bug affects me and therefore it is terrible". I get that, for you, this is an awful experience. But that experience is not universal. > I have found that the whole location bar search can be switched off by > setting keyword.enable to false. You might want to put this into the > preferences dialog somehow. 99.99% of people prefer the current behaviour, so we won't be doing this. We should just make sure that input in the location bar does the Right Thing.

I had gotten used to putting a trailing / on any hostname I wanted to navigate to directly. This had worked with Firefox, Chrome, IE in the past. Now it works everywhere but in Firefox. I have always found the default search behavior that I first found in Chrome very annoying which is why I had thought the trailing slash was the perfect common habit. It seem seems a bit strange when the location bar is choosing to go to a URL and when it is choosing to do a search. As an end user, I prefer being able to use a single character to indicate my intention, instead of having to type 7 of them or whitelist domains. Desired is: ?foo (current search provider search for foo) foo/ (navigate to http://foo) Looks like anything with a period in the location bar gets treated as a explicit location? i.e. put a.32 in the location bar and it will attempt to load http://www.a.32 . Is the goal to get rid of the search input and just use the location bar as the search input like is done in Chrome? When would I ever need to CTRL-K when ALT-D is just going to do the exact same thing all the time now?

(In reply to joe from comment #9) > Desired is: > ?foo (current search provider search for foo) "? foo" already works as you describe. You can also use "* foo" to make the location bar dropdown only show you bookmarked pages, and there's a few other similar shortcuts. As already noted, //foo will always use the hostname. > Looks like anything with a period in the location bar gets treated as a > explicit location? i.e. put a.32 in the location bar and it will attempt to > load http://www.a.32 . It's quite a bit more complicated than that, but yes, the presence of dots (or otherwise) is one thing we use in our heuristics. > Is the goal to get rid of the search input and just use the location bar as > the search input like is done in Chrome? While we might do that at some point, or might also not do that ever, the initial goal here is just to reduce the amount of waiting and/or error pages that people see, as they are generally just less useful than a search page. Try explaining to a normal person with no computing background why putting "bonsai tree" in the url bar gets you to google instantaneously, and putting "bonsai" didn't. Or why 42*42 did but 42/42 didn't. The basic assumption is that the location bar should DWIM. It should do that irrespective of the fate of the search box. Chrome is more aggressive in making things search than we are (try aliasing localhost to "foobar" and just typing "foobar" in the location bar), and that might stay that way, or they might make further adjustment. Either way, we will do our best to give most users the best experience. That may occasionally mean that as power users, we need to adapt our habits. To speak to the point in question, I'm not convinced "foo/" should not do a search. Using the accepted standard "protocol relative URL" as a shorthand here seems more intuitive to me (the fact that Chrome on OS X thinks I mean "file:///foo" is just Chrome being silly - I should be able to use a single slash for file URIs on Unix-like OSes).

If Google (who is pretty keen on searching) thinks that "foo/" shouldn't search, then it might be worth looking at again. I could live with changing from a single trailing slash (foo/) to double leading (//foo) if it worked in Chrome. Chrome in Windows takes me to a google search for //foo (it does work in IE though). I guess I will need to learn to love keyword.enabled as a power user until I there becomes a standard out-of-the-box way to navigate to specific URL using the Awesome/Omni (formerly location) inputs.

is foo./ working in Chrome ?

This "feature" is explained here: http://msujaws.wordpress.com/2014/08/01/faster-and-snappier-searches-now-in-firefox-aurora/ Like other reporters, I got used to entering 'wiki/' for accessing internal websites. Now this functionality is broken in Firefox 33. Please provide us with an about:config option (or extend the `browser.fixup.domainwhitelist.` option to accept a wildcard) that disables this behavior. Expected behavior: - 'foo' -> triggers search for 'foo' - 'foo/' -> visits http://foo/ - 'foo bar' -> searches for 'foo bar' - 'foo bar/' -> searches for 'foo bar/' I noticed that 'wiki./' is still accepted (but considered a bug by Mozilla developers).

Peter: Scroll up a bit. I found a suitable about:config option and suggested that it's put to the preferences GUI. Gijs: I'm pretty busy, hence not yet finished testing. I hope, I'll haev more time after the weekend.

@Stefan the keyword.enabled[1] option makes 'example/' point to 'http://www.example.com/' instead of http://wiki/. When Chromium introduced this change where 'foo/bar' would result in a search query, I was already quite annoyed. Please don't take this nonsense to Firefox too. [1]: http://kb.mozillazine.org/Keyword.enabled

(In reply to Peter Wu from comment #15) > This "feature" is explained here: > http://msujaws.wordpress.com/2014/08/01/faster-and-snappier-searches-now-in- > firefox-aurora/ > > Like other reporters, I got used to entering 'wiki/' for accessing internal > websites. Now this functionality is broken in Firefox 33. Please provide us > with an about:config option (or extend the `browser.fixup.domainwhitelist.` > option to accept a wildcard) that disables this behavior. > > Expected behavior: > > - 'foo' -> triggers search for 'foo' > - 'foo/' -> visits http://foo/ > - 'foo bar' -> searches for 'foo bar' > - 'foo bar/' -> searches for 'foo bar/' > > I noticed that 'wiki./' is still accepted (but considered a bug by Mozilla > developers). Why do you think "Mozilla developers" consider this a bug? (In reply to Peter Wu from comment #17) > @Stefan the keyword.enabled[1] option makes 'example/' point to > 'http://www.example.com/' instead of http://wiki/. Why would "example" point to "wiki" ? And, assuming this just a typo and you meant "wiki/" goes to "www.wiki.com/", I just disabled keyword.enabled and can't reproduce this (although I use an /etc/hosts alias, so maybe that's a factor?). It would be useful if you filed a separate bug about the domain correction kicking in there while it shouldn't, with more detailed STR (particularly more details about your setup, like if you're using search domains and wiki is really wiki.something.local or whatever). Also, try turning off browser.fixup.alternate.enabled . > When Chromium introduced this change where 'foo/bar' would result in a > search query, I was already quite annoyed. Please don't take this nonsense > to Firefox too. More generally to people commenting here: can we please stop with the "us vs. them" rhetoric, scare quotes, irrelevant comparisons to Chrome, and calling things we do "nonsense", as if it is objectively non-sensical, which it clearly isn't. It doesn't help fix the bug, and it does spam people CC'd and annoy developers.

(In reply to :Gijs Kruitbosch from comment #18) > (In reply to Peter Wu from comment #15) > [..] > > I noticed that 'wiki./' is still accepted (but considered a bug by Mozilla > > developers). > > Why do you think "Mozilla developers" consider this a bug? I was under the impression that bug 1042519 was filed for this behavior, but apparently I was wrong and it applies to "wiki." queries only (and not "wiki./"). > (In reply to Peter Wu from comment #17) > > @Stefan the keyword.enabled[1] option makes 'example/' point to > > 'http://www.example.com/' instead of http://wiki/. > > Why would "example" point to "wiki" ? And, assuming this just a typo and you > meant "wiki/" goes to "www.wiki.com/", I just disabled keyword.enabled and > can't reproduce this (although I use an /etc/hosts alias, so maybe that's a > factor?). Yes, it was a typo, it should be http://example/. Disabling keyword.enabled breaks searching from the location bar though (for obviously malformed "URLs" such as "foo bar"). > It would be useful if you filed a separate bug about the domain > correction kicking in there while it shouldn't, with more detailed STR > (particularly more details about your setup, like if you're using search > domains and wiki is really wiki.something.local or whatever). Also, try > turning off browser.fixup.alternate.enabled . Yes, disabling fixup.alternate.enabled disables the above behavior. More precisely: - example would redirect to http://www.example.com/ because there is no hosts/DNS entry for this - example would redirect to http://example/ when the fixup is disabled - wiki (with a corresponding DNS entry) would redirect to http://wiki/ in either configuration case What do you think of the idea to add an option to revert to the old behavior?

(In reply to Peter Wu from comment #19) > > It would be useful if you filed a separate bug about the domain > > correction kicking in there while it shouldn't, with more detailed STR > > (particularly more details about your setup, like if you're using search > > domains and wiki is really wiki.something.local or whatever). Also, try > > turning off browser.fixup.alternate.enabled . > > Yes, disabling fixup.alternate.enabled disables the above behavior. More > precisely: > > - example would redirect to http://www.example.com/ because there is no > hosts/DNS entry for this > - example would redirect to http://example/ when the fixup is disabled > - wiki (with a corresponding DNS entry) would redirect to http://wiki/ in > either configuration case Just to be clear, if there's no DNS nor hosts entry, you're getting a network error page for the host, right - or am I missing something? Why do you prefer that over a search query? And, as best I can tell, if DNS returns nothing for "foobar/" on 31 or 32, the same happens as what happens now: you get a search. It just takes longer. What part am I not understanding here? > What do you think of the idea to add an option to revert to the old behavior? So far, I've (as best I can tell) seen 4 different reasons for people to be unhappy about what we implemented for 33: 1) they hit bug 690307 and want the history dropdown to work properly. Solution: we should fix bug 690307, not add an option. 2) they have "hundreds" of local sites and adding whitelist entries for all of them is burdensome. This is bug 1088050. The only thing I can think of is adding an option. I really don't like adding options because, as you might have noticed, there are already something like 8 different options that control this behaviour, and all the permutations make the URL bar hard to test and ensure they all work correctly. Adding more is the wrong direction. 3) People want "foo/" to never use the whitelist because it works in other browsers. We could fix this without adding an option, but I would assume most of these people don't fall under (2), and so I'm also struggling to understand why clicking "Yes, take me to 'foo'" is such a burden and how much of this is surprise at the change rather than rational objections to the behaviour as present in 33. 4) You! Not sure where you fit in the above. :-)

(In reply to :Gijs Kruitbosch from comment #20) [..] > Just to be clear, if there's no DNS nor hosts entry, you're getting a > network error page for the host, right - or am I missing something? Why do > you prefer that over a search query? And, as best I can tell, if DNS returns > nothing for "foobar/" on 31 or 32, the same happens as what happens now: you > get a search. It just takes longer. What part am I not understanding here? I do not prefer getting the network error page, this is the result of setting keyword.enabled. In pre-33, wiki/ would first try to resolve the host 'wiki' through the resolver (hosts file, but more importantly, DNS). Since 33, this step is gone. > So far, I've (as best I can tell) seen 4 different reasons for people to be > unhappy about what we implemented for 33: > > 1) they hit bug 690307 and want the history dropdown to work properly. > Solution: we should fix bug 690307, not add an option. > 2) they have "hundreds" of local sites and adding whitelist entries for all > of them is burdensome. This is bug 1088050. The only thing I can think of is > adding an option. I really don't like adding options because, as you might > have noticed, there are already something like 8 different options that > control this behaviour, and all the permutations make the URL bar hard to > test and ensure they all work correctly. Adding more is the wrong direction. > 3) People want "foo/" to never use the whitelist because it works in other > browsers. We could fix this without adding an option, but I would assume > most of these people don't fall under (2), and so I'm also struggling to > understand why clicking "Yes, take me to 'foo'" is such a burden and how > much of this is surprise at the change rather than rational objections to > the behaviour as present in 33. > 4) You! Not sure where you fit in the above. :-) I have not noticed (1) yet. Option (2) would be applicable in my case. At work every host has an name such that we do not need to remember IP addresses, and then we can simply enter 'wiki', 'proj1', 'jira', etc. And (3) is something I would like to see. I have two issues with the "yes, take me to foo" option: 1. The full URL is leaked to an external party (and loads slightly slower). 'somehost/path/to/resource' becomes a search query too. 2. Clicking the button involves moving my hand from keyboard to mouse. Since the default action for users like me is to press "Yes, take me to 'foo'" for every host (dev.proj1, prod.proj1, test.proj1, ...), it would be convienient if the behavior is configurable. You could then have three levels: - For the users targeted by this change, do a search (default setting). - For users like me, do a host lookup. If it fails, do not do a search query (pre-33 behavior). This also ensures that no search query is done when the host fails to resolve (when moving between work and public networks for example). - As an intermediate option, you could prefer a host lookup and then perform a search query. This is a possibility, but I have no idea who would be interested in it. (4) is just an alias for (3) ;-)

(In reply to Peter Wu from comment #21) > (In reply to :Gijs Kruitbosch from comment #20) > [..] > > Just to be clear, if there's no DNS nor hosts entry, you're getting a > > network error page for the host, right - or am I missing something? Why do > > you prefer that over a search query? And, as best I can tell, if DNS returns > > nothing for "foobar/" on 31 or 32, the same happens as what happens now: you > > get a search. It just takes longer. What part am I not understanding here? > > I do not prefer getting the network error page, this is the result of > setting keyword.enabled. In pre-33, wiki/ would first try to resolve the > host 'wiki' through the resolver (hosts file, but more importantly, DNS). > Since 33, this step is gone. OK, thanks for clarifying. > > So far, I've (as best I can tell) seen 4 different reasons for people to be > > unhappy about what we implemented for 33: > > > > 1) they hit bug 690307 and want the history dropdown to work properly. > > Solution: we should fix bug 690307, not add an option. > > 2) they have "hundreds" of local sites and adding whitelist entries for all > > of them is burdensome. This is bug 1088050. The only thing I can think of is > > adding an option. I really don't like adding options because, as you might > > have noticed, there are already something like 8 different options that > > control this behaviour, and all the permutations make the URL bar hard to > > test and ensure they all work correctly. Adding more is the wrong direction. > > > 3) People want "foo/" to never use the whitelist because it works in other > > browsers. We could fix this without adding an option, but I would assume > > most of these people don't fall under (2), and so I'm also struggling to > > understand why clicking "Yes, take me to 'foo'" is such a burden and how > > much of this is surprise at the change rather than rational objections to > > the behaviour as present in 33. > > 4) You! Not sure where you fit in the above. :-) > > I have not noticed (1) yet. Option (2) would be applicable in my case. At > work every host has an name such that we do not need to remember IP > addresses, and then we can simply enter 'wiki', 'proj1', 'jira', etc. > > And (3) is something I would like to see. I have two issues with the "yes, > take me to foo" option: > > 1. The full URL is leaked to an external party (and loads slightly slower). > 'somehost/path/to/resource' becomes a search query too. Right, but it did this before if the host didn't exist, for instance if you switched networks (cf. the second point you raised below). > 2. Clicking the button involves moving my hand from keyboard to mouse. There's an access key, so alt-y (or ctrl-y on mac) should avoid this. If that's not underlined on Windows, or if the access key conflicts somehow, we should look at that (but that'd be a separate bug to keep things clear). > Since the default action for users like me is to press "Yes, take me to > 'foo'" for every host (dev.proj1, prod.proj1, test.proj1, ...), it would be > convienient if the behavior is configurable. Right. I'm a little surprised that the foo.bar things don't Just Work. They should, at least until bug 1080682 is fixed (will be a while, and in any case that will have its own "tld"-specific whitelist, so "proj1" would get you all of dev/prod/test.proj1). > You could then have three > levels: > > - For the users targeted by this change, do a search (default setting). > - For users like me, do a host lookup. If it fails, do not do a search > query (pre-33 behavior). This also ensures that no search query is done when > the host fails to resolve (when moving between work and public networks for > example). > - As an intermediate option, you could prefer a host lookup and then > perform a search query. This is a possibility, but I have no idea who would > be interested in it. This is the pre-33 behaviour, if I understand correctly. The reason we changed is speed: 99% of people mean to do a search, and DNS lookups in some environments are tragically slow. > (4) is just an alias for (3) ;-) Well, you can already do '//foo' to get to http://foo and save yourself some typing - or use the accesskey as per the above. Would the addition of the 'foo/' possibility make much of a difference for you personally? From my POV, it sounds like you're more in the (2) than the (3) camp. :-)

(In reply to :Gijs Kruitbosch from comment #22) [..] > > And (3) is something I would like to see. I have two issues with the "yes, > > take me to foo" option: > > > > 1. The full URL is leaked to an external party (and loads slightly slower). > > 'somehost/path/to/resource' becomes a search query too. > > Right, but it did this before if the host didn't exist, for instance if you > switched networks (cf. the second point you raised below). and it would also be nice if that could be improved by not doing another lookup as an option :-) > > 2. Clicking the button involves moving my hand from keyboard to mouse. > > There's an access key, so alt-y (or ctrl-y on mac) should avoid this. If > that's not underlined on Windows, or if the access key conflicts somehow, we > should look at that (but that'd be a separate bug to keep things clear). alt-y works for Linux, did not notice that. The first point still stands, I don't want the URL to get leaked to a search engine with the search URL ending up in history ('nother reason). > > Since the default action for users like me is to press "Yes, take me to > > 'foo'" for every host (dev.proj1, prod.proj1, test.proj1, ...), it would be > > convienient if the behavior is configurable. > > Right. I'm a little surprised that the foo.bar things don't Just Work. They > should, at least until bug 1080682 is fixed (will be a while, and in any > case that will have its own "tld"-specific whitelist, so "proj1" would get > you all of dev/prod/test.proj1). Oh, I typed that too fast, foo.bar URLs seems to work. proj1-staging, proj1-testing would still need a special case though. > This is the pre-33 behaviour, if I understand correctly. The reason we > changed is speed: 99% of people mean to do a search, and DNS lookups in some > environments are tragically slow. 1% × "half a billion"[1] = 5 million people that get ignored. Sorry, couldn't resist ;) [1]: http://blog.mozilla.org/press/ataglance/ > > (4) is just an alias for (3) ;-) > > Well, you can already do '//foo' to get to http://foo and save yourself some > typing - or use the accesskey as per the above. Would the addition of the > 'foo/' possibility make much of a difference for you personally? From my > POV, it sounds like you're more in the (2) than the (3) camp. :-) Actually, '//foo' gets me to file:////foo on Linux. It would even be better if 'foo' would be supported, but since Chromium required 'foo/', I got used to that as well. The best solution would be one where 'foo' does a host name lookup first (I am fine with fiddling once in about:config for this). If that is too much asked, then I would also be happy with 'foo/'. In any case, I do not consider the 'take me to X' button as solution for the three reasons mentioned before. Besides, I then have to manually whitelist every host (as alt-y just navigates to the host once).

(In reply to Peter Wu from comment #23) > <snip lots of bits that had me nodding> > > Well, you can already do '//foo' to get to http://foo and save yourself some > > typing - or use the accesskey as per the above. Would the addition of the > > 'foo/' possibility make much of a difference for you personally? From my > > POV, it sounds like you're more in the (2) than the (3) camp. :-) > > Actually, '//foo' gets me to file:////foo on Linux. It would even be better > if 'foo' would be supported, but since Chromium required 'foo/', I got used > to that as well. Oh, huh, yeah, file paths. We should fix that (as should Chromium). "://" works as a prefix, but meh, '//' should too (and does on Windows, just not on *nix, including mac). > The best solution would be one where 'foo' does a host name lookup first (I > am fine with fiddling once in about:config for this). If that is too much > asked, then I would also be happy with 'foo/'. OK. At least now I understand where you stand on this one. > In any case, I do not consider the 'take me to X' button as solution for the > three reasons mentioned before. Besides, I then have to manually whitelist > every host (as alt-y just navigates to the host once). Wait, are you saying that after clicking the button, with the same input (ie same host) as before, you still get a search and another prompt? That's not right - the button (and therefore alt-y) should do the whitelisting for you already! Might still be bug 690307, but if you're typing rather than using the history dropdown, that really shouldn't happen.

(In reply to :Gijs Kruitbosch from comment #24) [..] > > The best solution would be one where 'foo' does a host name lookup first (I > > am fine with fiddling once in about:config for this). If that is too much > > asked, then I would also be happy with 'foo/'. > > OK. At least now I understand where you stand on this one. I prefer the former though :D Less typing is always good. > > In any case, I do not consider the 'take me to X' button as solution for the > > three reasons mentioned before. Besides, I then have to manually whitelist > > every host (as alt-y just navigates to the host once). > > Wait, are you saying that after clicking the button, with the same input (ie > same host) as before, you still get a search and another prompt? That's not > right - the button (and therefore alt-y) should do the whitelisting for you > already! Might still be bug 690307, but if you're typing rather than using > the history dropdown, that really shouldn't happen. Ok, it turns out that Private Browsing is responsible for this. If I repeat it in the regular session, the persistence works.

One place where Firefox outshined Chrome prior to this 33 release was it's intelligent handling in the URL bar. If the query is a hostname -- go to it; if not -- treat it as a search string. Are users really expected to "prepend http:// to avoid the search" after years and years of having Firefox smartly handle hostnames in the URL bar? I see the user can set the keyword.enabled option to false if they want to get back hostname resolution and lose the URL bar as a query bar, but this is forcing the user to set an option to get back one feature they always had in previous releases while removing another feature they always had in previous releases. Net gain -1 either way. If the devs really want to follow this new path, then they should follow Chrome's lead in using the trailing slash to allow us to denote a hostname, e.g. "myserver/". Although, it always annoyed me that I have to type that extra slash in Chrome when I knew I could just type the server name in Firefox. In more than ten years of Firefox use this is the first misfeature that has ever been so bad that it's prompted me to open a Bugzilla account! Please address this either with a revert of this change, or the append-a-slash workaround. <3

(In reply to Stefan Gofferje from comment #2) > The high potential for accidentally leaking URL parameters by triggering a > search are a serious privacy and security concern which actually would > warrant a security warning and recommendation to not use Firefox! I second whole of comment #2 and I'd like to especially underline the security concerns. I guess that the vast majority of users do not have local servers, but still there are likely tens if not hundreds of thousands who do. They should not be exposed to security risks. My suggestion is to turn things around - to let the search bar accept URLs, and leave the address bar alone, for security reasons. So the user can choose if to use just one bar (which IMO isn't wise) or two separate bars for two distinct functions. Another suggestion: turn search from address bar off per default if there is a search bar visible. Inform the user that hiding of the search bar turns search functionality in the address bar on and that it is potentially privacy and security issue. I need to stress: a privacy and security issue.

Sorry to post again not having been directly replied to, but having now digested all the previous posts I just want to say this: This change seems to have been made because some developers think the majority of users want to search when they type in the URL bar rather than visit a host on their LAN. That may be true, but I want to point out that getting to a host on a LAN quickly is something technical users need to be able to do. Those same technical users often have some say over what software gets deployed at their workplace and can indirectly introduce hundreds or thousands of people to this software. I work at a company of about 2000 users and after the Systems team changed our default browser to Chrome I argued vehemently that we should stick with Firefox for its superior Linux support. I can no longer argue for this as all 2000 of our users regularly connect to hosts on our corporate network as part of their job by typing hostnames in the URL bar. Having to type "http://" before the hostname is not acceptable, and neither is having to click "yes" or remember an "alt-y" accelerator. It should just work the way it used to, or at worst follow Chrome's convention of requiring a trailing slash to indicate a hostname. It was already an uphill battle to suggest the Systems team go back to Firefox due to the time they put in to making Chrome work smoothly, but with this broken URL bar behavior it's even more difficult for me to make an argument for it. Please recognize this change as a mistake and fix it!

Apologies for the silence here on my part on this bug over the last 3 weeks. In those weeks, I've fixed bug 690307. That fix will be available in Firefox 34 which is to be released in a little over a week, if all goes to plan. This means that entries in the dropdown of the location bar will go where they say they go, and "http://" doesn't disappear out of the location bar and break editing the URL (comment #2, among others - note that this issue in principle predated the "search for single words" change, but was made a lot worse by it...). I've also just put up a patch for bug 1088050, which will add a hidden pref to turn this feature off. As it needs to be reviewed and possibly adjusted based on that review, I can't make any promises as to when that will ship, but I hope for Firefox 35 (it's basically too late to add things to 34 now, considering how soon it's releasing). I'm changing this bug to address the compatibility with chrome in that "foo/" should do a DNS lookup first, and sticking it in our backlog so it hopefully gets worked on "soon". (Jared, Dolske, Mike: I've CC'd you as a "heads up" as to where I think this is all going; please let me know if there is a need for further/other course-correction and/or if you have ideas on how to do better)

Wanted to help push for this task. Our company like many heavily use short intranet urls and having to type 'http://' before is really discouraging my automatic use of Firefox over competitors.

Well, that was fun. Blair, do these test changes look OK to you?

Note that on Windows (but not elsewhere, I *think*), this will also make "foo\" work as a domain ref, because we convert the slashes before the keywordtouri method gets invoked (see also: tests!). This seems to me like it'd be a feature rather than a bug, so I've left it like this.

remote: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=2a7fc5b75896

Comment on attachment 8539857 [details] [diff] [review] entering a trailing slash after a domain should not do a search, Review of attachment 8539857 [details] [diff] [review]: ----------------------------------------------------------------- I'm continually thankful for the test coverage we have for this.

Verified fixed on Nightly 37.0a1 (2015-01-06) using Ubuntu 12.04 LTS 32-bit, Mac OS X 10.9.5 and Windows 7 64-bit.

Comment on attachment 8539857 [details] [diff] [review] entering a trailing slash after a domain should not do a search, Approval Request Comment [Feature/regressing bug #]: bug 693808 and friends [User impact if declined]: people expect "foo/" to try to resolve "foo" before going to search, as it does in Chrome. Right now it doesn't do that, and this patch fixes that. [Describe test coverage new/current, TBPL]: pretty good! See also comment 36. [Risks and why]: pretty low, considering the baking time and the automated testing coverage [String/UUID change made/needed]: nope.

Verified fixed on Aurora 36.0a2 (2015-01-11) as well, using Ubuntu 12.04 LTS 32-bit, Windows 8.1 64-bit and Mac OS X 10.9.5.

So this will not be available until the 36 update? I am still staying on 32.0.3 version because this problem.

(In reply to Areg from comment #43) > So this will not be available until the 36 update? Indeed, this change arrived too late for 35.

(In reply to Sylvestre Ledru [:sylvestre] from comment #44) > (In reply to Areg from comment #43) > > So this will not be available until the 36 update? > Indeed, this change arrived too late for 35. Any details about the 36 official update?

(In reply to Areg from comment #45) > Any details about the 36 official update? Yes, it is going to be released on 2015-02-24. See: https://wiki.mozilla.org/RapidRelease/Calendar You can use the beta version if you prefer: https://www.mozilla.org/firefox/channel/#beta