Closed Bug 1397548 Opened 2 years ago Closed 2 years ago
fails to try attempt to navigate to httpd
.apache .org (actually any subdomain starting with http) in address bar
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20170906100107 Steps to reproduce: Enter httpd.apache.org in address bar and press enter or click the go arrow button. Actually it seems as any subdomain starting with http causes this issue (http.google.com, http.mozilla.org, httpabcdef.mozilla.org, http12345.google.com). You have to enter the http:// protocol prefix to navigate to httpd.apache.org or get a dns error page for the invalid hosts). Actual results: Nothing. If you are on a currently loaded page when this happens, it just shows the current page's url again with no navigation. Expected results: It should try to navigate to the address typed in the address bar.
[Tracking Requested - why for this release]: regression about navigation from location bar I can reproduce the problem and an error is shown in Browser Console when press [Enter]: NS_ERROR_MALFORMED_URI: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService2.newURI] 1 RemoteWebNavigation.js:20 Regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=47a2bf7ad9180afec62fb531f84a9cdd35823e58&tochange=780cc8989f5d971f780b04448c548f925ea0363c Regressed by:Bug 1383299 :evelyn Your patch seems cause the problem, could you look this?
Status: UNCONFIRMED → NEW
Component: Untriaged → Address Bar
Ever confirmed: true
This is caused by this condition: https://hg.mozilla.org/mozilla-central/rev/5790215bddcc#l1.35 This causes us to try to run makeURI() with an argument like "httpd.apache.org" which fails to parse as a URI. I think a good solution is to be smart on two levels, first is to check for strings starting with "http:" and "https:", and also to wrap the entire block in a try/catch in case makeURI throws since we can't have any guarantees on what the user types into the location bar.
Assignee: nobody → ehsan
Attachment #8905354 - Flags: review?(mconley)
Thank Ehsan for the patch! :)
Assignee: ehsan → ehung
(Sorry I was going to take the bug and forget to clear this before sending the comment above.....)
Assignee: ehung → ehsan
Comment on attachment 8905354 [details] [diff] [review] Patch (v1) Review of attachment 8905354 [details] [diff] [review]: ----------------------------------------------------------------- Great, thanks ehsan!
Attachment #8905354 - Flags: review?(mconley) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/1c4bb93c75ae Correctly deal with deceptively URI-looking content entered into the location bar in RemoteWebNavigation.loadURIWithOptions(); r=mconley
I have reproduced this bug with Nightly 57.0a1 (2017-09-06) on Windows 8.1 , 64 Bit ! This bug's fix is Verified with latest Beta 57.0b3 ! Build ID 20170925150345 User Agent Mozilla/5.0 (Windows NT 6.3; WOW64; rv:57.0) Gecko/20100101 Firefox/57.0
QA Whiteboard: [bugday-20170927]
I have reproduced this bug with Nightly 57.0a1 (2017-09-06) (64-bit) on Ubuntu 16.04 LTS! This bug's fix is Verified with latest Beta! Build ID 20170925150345 User Agent Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 [bugday-20170927]
As par Comment 9 & Comment 10 , I am marking this bug as Verified Fixed !
You need to log in before you can comment on or make changes to this bug.