Can't access host without tld

RESOLVED FIXED in Firefox 11



8 years ago
8 years ago


(Reporter: sonny, Assigned: mbrubeck)


Firefox 12
Dependency tree / graph

Firefox Tracking Flags

(firefox11 fixed, firefox12 fixed, fennec11+)


(Whiteboard: [has patch])


(1 attachment, 1 obsolete attachment)



8 years ago
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".
Assignee: nobody → mbrubeck
tracking-fennec: --- → 11+
Priority: -- → P2
Priority: P2 → P3

Comment 1

8 years ago
Same problem with "about:" pages

Comment 2

8 years ago
Posted patch patch (obsolete) — Splinter 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

8 years ago
Posted patch patch v2Splinter Review
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).
Attachment #591318 - Attachment is obsolete: true
Attachment #591328 - Flags: review?(wjohnston)


8 years ago
Whiteboard: [has patch]
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?
Attachment #591328 - Flags: review?(wjohnston) → review+

Comment 5

8 years ago
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:
Target Milestone: --- → Firefox 12


8 years ago
Blocks: 720932
Closed: 8 years ago
Resolution: --- → FIXED

Comment 7

8 years ago
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.
Attachment #591328 - Flags: approval-mozilla-aurora?
Comment on attachment 591328 [details] [diff] [review]
patch v2

[Triage Comment]
Mobile only - approved for Aurora.
Attachment #591328 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.