User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 (Beta/Release) Build ID: 20140731004002 Steps to reproduce: Type //intranetsite into the address bar. This is a common convention for disambiguating http domains from search terms Actual results: You get a search with a 'Did you mean to go to intranetsite?' ribbon at the top. Expected results: //intranetsite should have been opened.

The infobar was added in bug 693808, so there's no way this was caused by bug 982428. I should also note that this is Windows-specific, because on OS X and Linux //foo gets interpreted to be a file path instead (and did before, too).

Marco, can you add this to the upcoming iteration? It's a regression from my work in bug 693808, so I believe it needs fixing as soon as possible.

I added this to the 34.2 spreadsheet.

Regression, tracking.

This also changes behaviour on non-Windows to make //foo mean http://foo rather than file:////foo. Right now, file:////foo on my system seems to just show file:///foo, so I think that's fine, but it's not strictly necessary to fix the regression here, so we could alternatively take out the hunk in ConvertFileToStringURI and make the test OS-dependent in the block just below the initial array, only checking its current return values on Windows and checking for file:////mozilla on non-Windows.

Please make a minimal possible change here, since we need to fix this on Aurora too.

Comment on attachment 8467353 [details] [diff] [review] duff protocol should never keyword search, > // Fix up protocol string before calling KeywordURIFixup, because > // it cares about the hostname of such URIs: > nsCOMPtr<nsIURI> uriWithProtocol; >+ bool inputHadDuffProtocol = false; >+ >+ // Prune duff protocol schemes >+ // >+ // ://totallybroken.url.com >+ // //shorthand.url.com >+ // >+ if (StringBeginsWith(uriString, NS_LITERAL_CSTRING("://"))) >+ { >+ uriString = StringTail(uriString, uriString.Length() - 3); >+ inputHadDuffProtocol = true; >+ } >+ else if (StringBeginsWith(uriString, NS_LITERAL_CSTRING("//"))) >+ { Nit, } else if () { (But still trying to understand this all)

Comment on attachment 8467353 [details] [diff] [review] duff protocol should never keyword search, Those fixed, r+

(In reply to Olli Pettay [:smaug] from comment #8) > Comment on attachment 8467353 [details] [diff] [review] > duff protocol should never keyword search, > > Those fixed, r+ With only the existing stuff on Windows fixed (and per-platform tests for this input) and the nit from comment #7 addressed: remote: https://hg.mozilla.org/integration/fx-team/rev/563e54414f4a

I confirm that accessing //intranetsite via Location Bar now results in a redirection to that site, or to a network error page if intranetsite does not exist. Per my conversation with :Gijs, testing was done by making use of the browser.fixup.domainwhitelist.* pref on Nightly 34.0a1 (2014-08-07), under Windows 7 64-bit and Windows 8.1 Pro 64-bit. Leaving [qa+] until this fix reaches Aurora.

Comment on attachment 8467353 [details] [diff] [review] duff protocol should never keyword search, Approval Request Comment [Feature/regressing bug #]: 693808 [User impact if declined]: using //foo, where foo is aliased to localhost, does a search by default [Describe test coverage new/current, TBPL]: added automated test for this case in this patch, code path has automated testing already [Risks and why]: low, moved code and added a boolean depending on the existing code, should be restricted in its effect to only "//foo" and "://foo" input. [String/UUID change made/needed]: none

Verified fixed on Aurora 33.0a1 (2014-08-08) as well, using Windows 7 64-bit and Windows 8 32-bit.