Closed Bug 718296 Opened 9 years ago Closed 9 years ago

Can't access host without tld


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



(firefox11 fixed, firefox12 fixed, fennec11+)

Firefox 12
Tracking Status
firefox11 --- fixed
firefox12 --- fixed
fennec 11+ ---


(Reporter: sonny, Assigned: mbrubeck)



(Whiteboard: [has patch])


(1 file, 1 obsolete file)

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
Same problem with "about:" pages
Attached 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.
Attached 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)
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+
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
Blocks: 720932
Closed: 9 years ago
Resolution: --- → FIXED
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+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.