Since the patch on bug 1421766 landed geckodriver no longer connects to a Firefox instance that is launched by using a profile name like with the following capabilities:

1644624688072 webdriver::server DEBUG -> POST /session {"desiredCapabilities":{"moz:firefoxOptions":{"args":["-P","ca.ancilla.hangbrain"]}}}

I think in a case like that when the profile folder is not known we should not try to read the MarionetteActivePort file and instead fallback to awaiting for Marionette on the given (default) port to be started. Or with some more logic we could also try to read the profile managers INI file and retrieve the profile path.

James, can you please have a look?

Set release status flags based on info from the regressing bug 1421766

We could fix this, but fundamentally we don't really support this well. The problem is that FirefoxOptions.profile is set to None in FirefoxOptions::from_capabilities since there's no profile directory provided, and no custom profile provided. So then in LocalBrowser::new we set the profile to a new profile, write all the prefs and everything to that profile folder, but presumably end up starting Firefox with the named profile instead of the newly created one, which means we aren't using any of the required prefs.

I think the right solution here would be to actually figure out what profile directory is being used for the given profile name, and set the corrrect profile path from that, but I don't know how reasonable that is; I think we'd need to hardcode the per-platform locations of the profiles given there's no way to ask Firefox where the profile directories are. A second solution would be to make the profile argument an enum like

enum ProfileType {
  Path(PathBuf),
  Named,
  Temporary
}

or something, and then we could handle the named case seperately and not create a profile that later won't be used, or try to read the profile port from it. But that won't fix the problem that we can't guarantee the named profile is configured in a way that works with marionette.

With named profiles we can't expect to write prefs, or to read the port out
of the profile path. So don't do these things.

https://hg.mozilla.org/mozilla-central/rev/60112720bf9b
https://hg.mozilla.org/mozilla-central/rev/b886dba8598e