Andreas Tolfsen ❲:ato❳ Assignee
	Description • 7 years ago

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.

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 1 • 7 years ago

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

	Andreas Tolfsen ❲:ato❳ Assignee
	Comment 2 • 6 years ago

This should be on the backlog.

	Andreas Tolfsen ❲:ato❳ Assignee
	Comment 3 • 6 years ago

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.

	Andreas Tolfsen ❲:ato❳ Assignee
	Comment 4 • 6 years ago

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.

	Andreas Tolfsen ❲:ato❳ Assignee
	Comment 5 • 6 years ago

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