To make it possible to connect to geckodriver on either IP transport
layer (IPv4 or IPv6), we should stop hardcoding geckodriver’s HTTPD
to listen on 127.0.0.1.

If we assign localhost to it, we can rely on system to tell us which
IP layer to listen on. Most system allow both, so this would make
it possible to connect on both ::1 and 127.0.0.1.

Originally reported in https://github.com/mozilla/geckodriver/issues/1496.

So we originally forced that in geckodriver 0.21.0 due to:

On certain system configurations, where localhost resolves to
an IPv6 address, geckodriver would attempt to connect to Firefox
on the wrong IP stack, causing the connection attempt to time out
after 60 seconds. We now ensure that geckodriver uses IPv4
consistently to both connect to Firefox and for allocating a free
port.

I assume that this problem is solved?

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #1)

So we originally forced that in geckodriver 0.21.0 due to:

On certain system configurations, where localhost resolves to
an IPv6 address, geckodriver would attempt to connect to Firefox
on the wrong IP stack, causing the connection attempt to time out
after 60 seconds. We now ensure that geckodriver uses IPv4
consistently to both connect to Firefox and for allocating a free
port.

I assume that this problem is solved?

You are confusing the Marionette socket, limited by nsIServerSocket,
with the client-facing HTTPD socket.

Well, please read bug 1462040 first, if that change was faulty or not. I don't want to introduce the old faulty behavior again.

We have to make sure that geckodriver always used IPv4 for the Marionette connection. So we might need two independent host definitions here.

#[markdown(off)]

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #3)

> Well, please read bug 1462040 first, if that change was faulty or
> not. I don't want to introduce the old faulty behavior again.
>
> We have to make sure that geckodriver always used IPv4 for the
> Marionette connection. So we might need two independent host
> definitions here.

Again, this is not related to the Marionette connection.

I only wanted to ensure we do not regress this part. But yes, I know that this bug is only for geckodriver. So we are talking about the following lines:

https://searchfox.org/mozilla-central/rev/5e3bffe964110b8d1885b4236b8abd5c94d8f609/testing/geckodriver/src/main.rs#78
https://searchfox.org/mozilla-central/rev/5e3bffe964110b8d1885b4236b8abd5c94d8f609/testing/geckodriver/src/main.rs#155

I’ve run in to a number of snags fixing this bug:

1. We rely on IpAddr which takes a variant of either an
   IPv4 or IPv6 address. It appears hyper only accepts one of the
   two. More investigation needed.

2. Flag errors are emitted using the error!() macro from the
   log crate, and these are not visible unless the log level is
   cranked up, which we cannot guarantee at the point of parsing
   flags.

3. Error descriptions aren’t included in the error we print to
   the user. We reduce it to just a generic custom message, and
   throw away the error description.

As 2 and 3 must be fixed together, I’ve filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1526938 about this and
made this bug depend on fixing that first.

https://users.rust-lang.org/t/how-to-listen-on-all-interfaces-with-tcplistener-solved/12269/4 seems relevant.

Sadly we don't have the capacity right now to handle that addition.

James, is there actually something left to do here? We seem to do well with listening on both interfaces these days, right?

We at least support listening on an IPv6 address, even though we still default to IPv4. I think that's probably OK; we could consider changing the default to bind to localhost, but should maybe be a different bug.