1302004 - Location bar search for a numeric division (e.g. 123/2) with no internal spaces suggests navigating to an IP address (e.g. "0.0.0.123")

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Chris Peterson [:cpeterson]]

Gijs, this looks like another regression from IP address bug 1288049, similar to bug 1299391.

STR:
1. Search for a numeric expression in the location bar, such as 123/2

RESULT:
Firefox will show an info bar asking "Did you mean to go to 0.0.0.123?"

I entered a numeric expression in the location bar because I wanted to use Google's calculator function.

Comment 1

[:Gijs (he/him)]

This only happens with division, and if there's no spaces in your query, because only then does it look like something where the host is 123 and the path is 2.

Comment 2

[:Gijs (he/him)]

Attachment: Bug 1302004 - go back to relying on the asciiHost instead of the input when determining whether to show an info bar, as it more reliably corresponds to the host only in expressions like 123/2,

The patch uses a combination of IPv4 detection and the existing regexp check, for reasons outlined in the patch. The network-level normalization for URIs catches some of the numbers-only IP requests, but not all of them.

Review commit: https://reviewboard.mozilla.org/r/78416/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/78416/

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8790713 [details]
Bug 1302004 - go back to relying on the asciiHost instead of the input when determining whether to show an info bar, as it more reliably corresponds to the host only in expressions like 123/2,

https://reviewboard.mozilla.org/r/78416/#review77354

::: browser/base/content/browser.js:712
(Diff revision 1)
> +  // but still work to access IP addresses. So for instance,
> +  // 1097347366913 (ff7f000001) gets resolved by using the final bytes,
> +  // making it the same as 7f000001, which is 127.0.0.1 aka localhost.
> +  // While 2130706433 would get normalized by network, 1097347366913
> +  // does not, and we have to deal with both cases here:
> +  if (isIPv4Address(asciiHost) || /^\d+$/.test(asciiHost))

Why did https://bugzilla.mozilla.org/show_bug.cgi?id=1299391 change this from asciiHost to fixupInfo.originalInput.trim() and now this patch is changing it back to asciiHost?

::: browser/base/content/test/urlbar/browser_urlbarSearchSingleWordNotification.js:35
(Diff revision 1)
>      notificationObserver = new MutationObserver(checkForNotification);
>      notificationObserver.observe(notificationBox, {childList: true});
>    } else {
>      setTimeout(() => {
> -      is(notificationBox.getNotificationWithValue(value), null, "We are expecting to not get a notification");
> +      is(notificationBox.getNotificationWithValue(value), null,
> +         "We are expecting to not get a notification for " + input);

Please use a template string here.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8790713 [details]
Bug 1302004 - go back to relying on the asciiHost instead of the input when determining whether to show an info bar, as it more reliably corresponds to the host only in expressions like 123/2,

https://reviewboard.mozilla.org/r/78416/#review77354

> Why did https://bugzilla.mozilla.org/show_bug.cgi?id=1299391 change this from asciiHost to fixupInfo.originalInput.trim() and now this patch is changing it back to asciiHost?

Sorry, I see you answered this in the commit message summary.

Comment 5

[:Gijs (he/him)]

Comment on attachment 8790713 [details]
Bug 1302004 - go back to relying on the asciiHost instead of the input when determining whether to show an info bar, as it more reliably corresponds to the host only in expressions like 123/2,

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/78416/diff/1-2/

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fd2adbce4faf
go back to relying on the asciiHost instead of the input when determining whether to show an info bar, as it more reliably corresponds to the host only in expressions like 123/2, r=jaws

Comment 7

[Carsten Book [:Tomcat]]

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

Comment 8

[Mohammad Maruf Rahman]

I have reproduced this bug with Nightly 51.0a1 (2016-09-11) (64-bit) on Windows 7 , 64 Bit !

This bug's fix is verified with latest Aurora

Build  ID    20160921004005
User Agent   Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0 

 [bugday-20160921]

Comment 9

[:Gijs (he/him)]

Thanks.