As described in https://github.com/SeleniumHQ/selenium/pull/4278 there is a potential race condition when geckodriver binds to port 0 to have the system atomically find a free port for Marionette. It then releases the port and writes it to the marionette.port preference. Firefox then some time later binds to this port. With https://bugzilla.mozilla.org/show_bug.cgi?id=1358988, Marionette started writing the effective port to marionette.port after it has bound. This means geckodriver can set marionette.port to 0 and then later read this preference from the profile. This would eliminate the race condition. It should be fine to make this change now as we will target Firefox 55 and greater with the next release (0.19.0 or greater) of geckodriver.

See also bug 1240830 for Marionette client. Given that geckodriver always launches the application itself, it's indeed easier to do.

This should be on the backlog.

I had a look at this and the complication is the “wait for marionette.port to be written to the profile on disk” part. I/O related operations are always prone to fail and the pref doesn’t get written immediately after startup. I don’t know if polling or using something like epoll to watch for a file write is the better option, as it is entirely possible the profile gets written to multiple times.

Did an implementation polling the preference file locally and it seems to work well. I am however still concerned about the continued file reading. Reversing the client/server relationship would be one option that could make this entirely atomic, so that Marionette would connect to a port geckodriver was listening on.

After looking into this some more, I’m more convinced that the right solution to this is to implement a dial-back approach where the client/server relationship is reversed. This is discussed in more detail in [1]. Reversing the relationship is itself quite easy, but would mean quite a lot of changes would need to be made to transport.js. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1240830