IPv6 address support

[Singijeon]

Now IPv6 address redirects to search page.

[marek22k]

Personally, I think that's also very good.

[kevinmcmurtrie]

This breaks access to non-cloud personal network devices.

It also breaks the advantage of IPv6 devices being very difficult to scan and probe, which is important for low power devices. This bug delivers the address to an external search engine.

[CharmCityCrab]

This appears to be an upstream bug inherited from Fenix:

https://bugzilla.mozilla.org/show_bug.cgi?id=1803465

https://bugzilla.mozilla.org/show_bug.cgi?id=1807752

https://github.com/mozilla-mobile/android-components/pull/5546

https://bugzilla.mozilla.org/show_bug.cgi?id=1807752

https://github.com/mozilla-mobile/fenix/issues/4343

Some of those may be duplicates- Fenix moved at least some of it's development from Github to Bugzilla a while back, and it created some cross-site copies of the same bug reports and comments.

Anyhow, in similar cases, it often makes sense for a fork with a smaller development team to simply wait for Fenix to fix upstream issues and then let the fixes filter down into Iceraven as Fenix updates are incorporated into Iceraven code as a matter of course.

However, this has apparently been a bug since 2019- back when Fenix was just a beta and hadn't even become the basis for official Firefox yet (Which happened in 2020). When something like this hasn't been fixed in 4 years by a medium to large browser company, maybe it becomes something that Iceraven could address. It probably depends on it's complexity and the willingness of Iceraven developers to put in the time to fix and maintain it either indefinitely if Firefox devs never get around to it, until Firefox develops its own fix (Which a hypothetical Iceraven fix could optionally be replaced with for ease of continued Iceraven maintenance), or until Fenix/Firefox picks up the hypothetical Iceraven fix (We're all open source code under the same licenses, they can do that. :) ) and starts maintaining said hypothetical fix as part of Fenix.

I wonder if Mull has a current fix we could add. Tagging their dev, @relan

What about Tor for Android? I can't imagine they'd leave this in for long, but their solution might be just to force everyone to IPv4 only and cut out IPv6 support, which isn't sustainable. A browser without IPv6 support is on borrowed time in 2023.

If a fix isn't in the cards in the near term, we might want to consider a user option in the GUI to turn off IPv6 entirely for those who want it turned off (Maybe with a pop-up warning message mentioning the downside and asking if people are sure), but the default should be to keep IPv6 enabled IMO (Ideally, fixed, but even if not...).

Is there an about:config option in Fenix that individual users can activate to turn off IPv6 if desired? We do make a point of mentioning that about:config is something you can access in Iceraven that you can't access in stable Firefox. It isn't (I'm told) as useful on mobile as on desktop, but it might have a toggle.

Also, just to check on the severity of this- Is this only submitting iPv6 results to a search engine when the URLs are entered directly as numbers, or does it do the same thing when someone enters them in the more typical fashion (i.e. http://www.example.com) and has them invisibly translated into the numbers that really make up the web?

Are the results being sent to the user's default search engine, or specifically to Google, regardless of the user's choice of search engine (I'd feel better if these were being forwarded to, say, duck.com [My default] and not Google for obvious reasons)?

[kevinmcmurtrie]

It's a bug in the unified search bar's detection of URLs. http://[2600:1700:2320:9090::2c]/Misc/yay.txt is seen as a search query. https://pixelmemory.us/Misc/yay.html uses the same URL in an HREF successfully.

[akliuxingyuan]

https://bugzilla.mozilla.org/show_bug.cgi?id=1803465 fixed in firefox122