Last Comment Bug 718296 - Can't access host without tld
: Can't access host without tld
[has patch]
Product: Firefox for Android
Classification: Client Software
Component: General (show other bugs)
: Trunk
: All All
P3 normal (vote)
: Firefox 12
Assigned To: Matt Brubeck (:mbrubeck)
: Sebastian Kaspari (:sebastian)
Depends on:
Blocks: 720932
  Show dependency treegraph
Reported: 2012-01-15 08:15 PST by Sonny Piers [:sonny]
Modified: 2012-01-26 17:32 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (1.36 KB, patch)
2012-01-24 16:30 PST, Matt Brubeck (:mbrubeck)
no flags Details | Diff | Splinter Review
patch v2 (1.64 KB, patch)
2012-01-24 16:57 PST, Matt Brubeck (:mbrubeck)
wjohnston2000: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description User image Sonny Piers [:sonny] 2012-01-15 08:15:28 PST
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 User image Sonny Piers [:sonny] 2012-01-24 13:49:54 PST
Same problem with "about:" pages
Comment 2 User image Matt Brubeck (:mbrubeck) 2012-01-24 16:30:56 PST
Created attachment 591318 [details] [diff] [review]

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?

(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 User image Matt Brubeck (:mbrubeck) 2012-01-24 16:57:58 PST
Created attachment 591328 [details] [diff] [review]
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:

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 User image Wesley Johnston (:wesj) 2012-01-24 17:31:06 PST
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 User image Matt Brubeck (:mbrubeck) 2012-01-24 18:44:07 PST
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:
Comment 6 User image :Ms2ger (⌚ UTC+1/+2) 2012-01-25 07:08:29 PST
Comment 7 User image Matt Brubeck (:mbrubeck) 2012-01-25 09:43:28 PST
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 User image Alex Keybl [:akeybl] 2012-01-25 17:04:42 PST
Comment on attachment 591328 [details] [diff] [review]
patch v2

[Triage Comment]
Mobile only - approved for Aurora.
Comment 9 User image Matt Brubeck (:mbrubeck) 2012-01-26 17:32:39 PST

Note You need to log in before you can comment on or make changes to this bug.