907066 - Single-word searches broken if word is a hostname (or behind proxy)

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect)

Description

[primexx]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36

Steps to reproduce:

Happens on all versions as far as I can tell. I'm currently on 23

1. Enable URL bar search
2. type a single word in the URL bar, while either:
2a. the word is a hostname (but isn't a webserver)
2b. Firefox is configured to use a proxy
3. hit 'enter'


Actual results:

Firefox doesn't conduct a URL bar search like it should, but rather tries to resolve the single word.


Expected results:

Do the usual URL bar search.

I recognize that there are some situations where simple hostnames are useful, but this is likely in the minority in consumer contexts.

The PROBLEM isn't that Firefox tries to resolve hostnames, but rather than there isn't (as far as I can tell) a pref to ignore hostnames and just do a URL bar search for ALL the things regardless.

Comment 1

[Michael]

I'll do a little tinkering on this one.

Comment 2

[Michael]

Attachment: Tentative patch for review/feedback.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Looks like that patch is adding a preference (keyword.allSimpleHosts), which I don't think we want to do (it won't benefit most users).

This bug is related to bug 700470. See also bug 700474 and bug 861509. If there's an easy way to fix this problem without a complicated solution like the ones proposed there, I'm all for it, but I somewhat doubt that there is - this is a tricky problem.

Comment 4

[primexx]

(In reply to Michael from comment #2)
> Created attachment 793626 [details] [diff] [review]
> Tentative patch for review/feedback.

Thank you! I don't have the skills to do this myself so I really appreciate your work.

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #3)
> Looks like that patch is adding a preference (keyword.allSimpleHosts), which
> I don't think we want to do (it won't benefit most users).

I don't understand your reasoning. There are LOTS of prefs that won't affect most users, and about:config is already a hidden interface for advanced configuration. Why does it have to benefit most users to add one line in prefs.js? You can even make it not appear by default, but just do something if you manually add the pref, like plenty that I've seen.
 
> This bug is related to bug 700470. See also bug 700474 and bug 861509. If
> there's an easy way to fix this problem without a complicated solution like
> the ones proposed there, I'm all for it, but I somewhat doubt that there is
> - this is a tricky problem.

Adding a pref as I suggested, and Michael implemented, seems like a simple and straightforward solution to toggling "ignore simple hostnames". I don't think this is complicated at all.

Comment 5

[Patrick McManus [:mcmanus]]

Comment on attachment 793626 [details] [diff] [review]
Tentative patch for review/feedback.

This will make dotless hostnames fail to resolve in all contexts - not just the location bar. That's going to be some serious intranet breakage. This needs to be more targetted.

Gavin - can prefs be accessed off the main thread now? I didn't think so - but they have a THREADSAFE_ISUPPORTS macro going on..

Comment 6

[Michael]

This is what I propose to do:
Set a uint pref controlling the mode of operation.

Case 0 (default): What we've always done. If DNS resolves, attempt to connect, else search.

Case 1: Search, but resolve DNS in the background. If it returns valid, show a notification to offer an option to go there. 

( Eg. "Did you mean http://foo/ ?" )

The user can disable the notification if they want through a bitmask in the pref.

Opinions?

Comment 7

[primexx]

(In reply to Michael from comment #6)
> This is what I propose to do:
> Set a uint pref controlling the mode of operation.
> 
> Case 0 (default): What we've always done. If DNS resolves, attempt to
> connect, else search.
> 
> Case 1: Search, but resolve DNS in the background. If it returns valid, show
> a notification to offer an option to go there. 
> 
> ( Eg. "Did you mean http://foo/ ?" )
> 
> The user can disable the notification if they want through a bitmask in the
> pref.
> 
> Opinions?

The "Did you mean" prompt is exactly what Chrome does. Sounds like a good compromise.

I don't understand what you mean by bitmask though

Comment 8

[Michael]

(In reply to primexx from comment #7)
> (In reply to Michael from comment #6)
> > This is what I propose to do:
> > Set a uint pref controlling the mode of operation.
> > 
> > Case 0 (default): What we've always done. If DNS resolves, attempt to
> > connect, else search.
> > 
> > Case 1: Search, but resolve DNS in the background. If it returns valid, show
> > a notification to offer an option to go there. 
> > 
> > ( Eg. "Did you mean http://foo/ ?" )
> > 
> > The user can disable the notification if they want through a bitmask in the
> > pref.
> > 
> > Opinions?
> 
> The "Did you mean" prompt is exactly what Chrome does. Sounds like a good
> compromise.
> 
> I don't understand what you mean by bitmask though

Eg a decimal number can be represented in binary as so:

... 0000 0000 0000
In our case, the last bit toggles the mode, and the second-to-last bit controls whether we show the prompt.

So valid cases would be 0 (default), 1 (Case 1 with prompt) 2 (Default since Case 0) and 3 (Case 1, no prompt).

Comment 9

[primexx]

(In reply to Michael from comment #8)
> Eg a decimal number can be represented in binary as so:
> 
> ... 0000 0000 0000
> In our case, the last bit toggles the mode, and the second-to-last bit
> controls whether we show the prompt.
> 
> So valid cases would be 0 (default), 1 (Case 1 with prompt) 2 (Default since
> Case 0) and 3 (Case 1, no prompt).

Ah that makes sense, thanks!

Comment 10

[:Gavin Sharp [email: [e-mail]]]

(In reply to primexx from comment #4)
> I don't understand your reasoning. There are LOTS of prefs that won't affect
> most users, and about:config is already a hidden interface for advanced
> configuration. Why does it have to benefit most users to add one line in
> prefs.js? You can even make it not appear by default, but just do something
> if you manually add the pref, like plenty that I've seen.

There's always a judgement call involved about whether the tradeoff is worth it. But see http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/ for some explanations about why you'll often get push back when suggesting "just add a pref".

> Adding a pref as I suggested, and Michael implemented, seems like a simple
> and straightforward solution to toggling "ignore simple hostnames". I don't
> think this is complicated at all.

It's only a solution for people who know about the pref, which is going to be effectively 0% of our users. So the value is very low.

Comment 11

[primexx]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #10)
> There's always a judgement call involved about whether the tradeoff is worth
> it. But see http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/
> for some explanations about why you'll often get push back when suggesting
> "just add a pref".

I see, it does raise potential QA testing complications.

However the current behaviour is evidently an annoyance to enough people that there are multiple BugZilla entries reporting it as broken. The answer has usually been "it's a feature", which doesn't really help much, hence this request to alter that behaviour or provide an option to do so.

If not a pref, what's a better way to go about this? Just ignoring the issue with the excuse that the only proposed solution isn't ideal in all respects isn't going to address it.

> It's only a solution for people who know about the pref, which is going to
> be effectively 0% of our users. So the value is very low.

I would imagine that the subset of users who would care about simple hostname behaviour would also very likely be googling whether a work-around or pref does in fact exist. so user-knowledge shouldn't be an issue here.

Comment 12

[AdityaSingh [:MacroMayhem]]

I would like to work to solve this bug.

Comment 13

[andydecleyre]

This has been a frustrating issue with no fix for a long time, through a huge number versions. I am with primexx in this case: a fix is far better than no fix. Thank you to Michael Shuen for the patch! Can anyone confirm if the patch is still compatible with the latest firefox? If so, and if it won't get merged officially, I'll start maintaining my own branch.

Comment 14

[primexx]

This issue has long since been resolved by Firefox implementing a feature doing essentially exactly what's requested.