Closed Bug 1047600 Opened 7 years ago Closed 7 years ago

bug 982428 regressed using //foo to go to an intranet site


(Firefox :: Address Bar, defect)

33 Branch
Windows 8
Not set



Firefox 34
Tracking Status
firefox33 + verified
firefox34 + verified


(Reporter: samlh+bz, Assigned: Gijs)



(Keywords: regression)


(1 file)

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.
Blocks: 982428
Component: Untriaged → Location Bar
Keywords: regression
OS: Windows 8 → All
Hardware: x86_64 → All
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).
Blocks: 693808
No longer blocks: 982428
Flags: firefox-backlog+
OS: All → Windows 8
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.
Assignee: nobody → gijskruitbosch+bugs
Iteration: --- → 34.3
Points: --- → 3
Ever confirmed: true
Flags: needinfo?(mmucci)
I added this to the 34.2 spreadsheet.
Flags: needinfo?(mmucci)
Regression, tracking.
Iteration: 34.3 → 34.2
QA Whiteboard: [qa+]
QA Contact: alexandra.lucinet
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.
Attachment #8467353 - Flags: review?(bugs)
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
>+    //
>+    //   ://
>+    //   //
>+    //
>+    if (StringBeginsWith(uriString, NS_LITERAL_CSTRING("://")))
>+    {
>+        uriString = StringTail(uriString, uriString.Length() - 3);
>+        inputHadDuffProtocol = true;
>+    }
>+    else if (StringBeginsWith(uriString, NS_LITERAL_CSTRING("//")))
>+    {

} 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+
Attachment #8467353 - Flags: review?(bugs) → review+
(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:

Flags: in-testsuite+
Whiteboard: [fixed-in-fx-team]
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 34
QA Contact: alexandra.lucinet → andrei.vaida
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
Attachment #8467353 - Flags: approval-mozilla-aurora?
Attachment #8467353 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified fixed on Aurora 33.0a1 (2014-08-08) as well, using Windows 7 64-bit and Windows 8 32-bit.
QA Whiteboard: [qa+] → [qa!]
See Also: 1221560
You need to log in before you can comment on or make changes to this bug.