718296 - Can't access host without tld

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect, P3)

Description

[Sonny Piers [:sonny]]

I'm trying to open http://sonny-laptop which is a resource on my local network.
Fennec launches a google search for "http://sonny-laptop".

Comment 1

[Sonny Piers [:sonny]]

Same problem with "about:" pages

Comment 2

[Matt Brubeck (:mbrubeck)]

Attachment: patch

This patch is untested because my network is not easily set up for me to add local domain name entries.

(In reply to Sonny Piers [:sonny] from comment #0)
> I'm trying to open http://sonny-laptop which is a resource on my local
> network.

Can you try this using this test build?
https://people.mozilla.com/~mbrubeck/fennec-718296.apk

(In reply to Sonny Piers [:sonny] from comment #1)
> Same problem with "about:" pages

Are you still seeing this problem with about: pages?  That should have been fixed several weeks ago by bug 710302.

Comment 3

[Matt Brubeck (:mbrubeck)]

Attachment: patch v2

I managed to test the previous patch and found some problems with it.  This one is better.  There's a new test build at:

https://people.mozilla.com/~mbrubeck/fennec-718296-b.apk

With this patch, rather than immediately sending any "search-like" string to the default search engine, we use the same "third-party fixup" flag that desktop Firefox and XUL fennec use.  This attempts a network lookup, and then uses the default search engine as a fallback.

One way to test this bug is to enter "localhost" in the URL bar.  The desired behavior is to load "http://localhost/" which should display a network error page (unless you have a web server running on port 80 of your device).

Comment 4

[Wesley Johnston (:wesj)]

Comment on attachment 591328 [details] [diff] [review]
patch v2

Review of attachment 591328 [details] [diff] [review]:
-----------------------------------------------------------------

I think this looks fine. Asked for a comment below:

::: mobile/android/chrome/content/browser.js
@@ +757,5 @@
>    getSearchOrFixupURI: function(aParams) {
>      let uri;
>      if (aParams.engine) {
>        let engine;
> +      if (aParams.engine != "__default__")

I think this is making me not like this API. Java is requesting the default search. We basically ignore it.

But Firefox will still use the default search if attempting to load the site fails. Is that right? Can we at least throw in a comment explaining that?

Comment 5

[Matt Brubeck (:mbrubeck)]

Pushed with an added comment, and I'll file a cleanup patch in a follow-up bug that I think will make this API nicer:

https://hg.mozilla.org/integration/mozilla-inbound/rev/fbd97e481850

Comment 6

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/fbd97e481850

Comment 7

[Matt Brubeck (:mbrubeck)]

Comment on attachment 591328 [details] [diff] [review]
patch v2

[Approval Request Comment]
User impact if declined:
Can't navigate to certain hostnames on mobile.

Testing completed (on m-c, etc.):
Test builds posted on 1/24.  Landed on m-c on 1/25.

Risk to taking this patch (and alternatives if risky): 
The patch is mobile-only.  It changes the default flags use for every URI load in the browser, but the new defaults match the ones desktop Firefox and XUL Fennec have always used, so I still believe this is low-risk.  The main regression risk is that it could potentially change some addresses that were previously interpreted as searches to now be interpreted as URIs.

Comment 8

[Alex Keybl [:akeybl]]

Comment on attachment 591328 [details] [diff] [review]
patch v2

[Triage Comment]
Mobile only - approved for Aurora.

Comment 9

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/93c85537ac1b