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

VERIFIED FIXED in Firefox 33

Status

()

defect
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: samuel.l.harrington, Assigned: Gijs)

Tracking

({regression})

33 Branch
Firefox 34
All
Windows 8
Points:
3
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +

Firefox Tracking Flags

(firefox33+ verified, firefox34+ verified)

Details

Attachments

(1 attachment)

Reporter

Description

5 years ago
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.
Reporter

Updated

5 years ago
Blocks: 982428
Component: Untriaged → Location Bar
Keywords: regression
OS: Windows 8 → All
Hardware: x86_64 → All
Assignee

Comment 1

5 years ago
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
Assignee

Comment 2

5 years ago
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
Status: UNCONFIRMED → ASSIGNED
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
Assignee

Comment 5

5 years ago
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
>+    //
>+    //   ://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+
Attachment #8467353 - Flags: review?(bugs) → review+
Assignee

Comment 9

5 years ago
(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
Flags: in-testsuite+
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/563e54414f4a
Status: ASSIGNED → RESOLVED
Last Resolved: 5 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.
Status: RESOLVED → VERIFIED
Assignee

Comment 12

5 years ago
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!]
Assignee

Updated

4 years ago
See Also: 1221560
You need to log in before you can comment on or make changes to this bug.