Bugzilla

Given the discussion from comment 13 and comment 14 lets follow the approach by using a file in the profile directory to indicate the port as used by Marionette. It's actually backed by our partial CDP implementation where I'm about to land a patch that does the same thing (bug 1706581).

Because there is a bit more work to do here I'm going to transform this bug into a meta bug, and will update the dependency list for all the bits and pieces we have to take care. In general I'm thinking of the following strategy:

1. Start Marionette writing the file to the profile directory (maybe lets also include the feature for the BiDi implementation). This patch should be uplifted to the 91ESR branch, and if possible even the 78ESR branch to allow geckodriver sooner than later to make use of the new technique.

2. Update the Marionette client and harness code to handle the scenario when `port=0` is requested by a consumer. We should still keep `2828` as default to not cause incompatibilities with not yet updated consumers. Here we don't have to uplift patches. Here we do not have to care about backward compatibility (we do not push releases to pypi anymore) and can allow the code to ride the train. But the question is how we have to handle the Android scenario given that we do not have proper Android support for the harness (bug 1607210).

3. Update web-platform-tests to request port `0` from marionette client instead of finding a free port on its own, which is racy. And for sure looking for that file, and reading the port once it exists.

4. Update geckodriver to allow handling of port `0` (bug 1421766), whereby we would first need support for pulling files from the Android device (bug 1725622). By default we should keep port `2828` until we know it runs all stable.

5. At a later time consider using port `0` as default.

Lets discuss this topic in next week's triage meeting.

Given the discussion from comment 13 and comment 14 lets follow the approach by using a file in the profile directory to indicate the port as used by Marionette. It's actually backed by our partial CDP implementation where I'm about to land a patch that does the same thing (bug 1706581).

Because there is a bit more work to do here I'm going to transform this bug into a meta bug, and will update the dependency list for all the bits and pieces we have to take care. In general I'm thinking of the following strategy:

1. Start Marionette writing the file to the profile directory (bug 1735162) and maybe lets also include the feature for the BiDi implementation (bug 1749673). This patch should be uplifted to the 91ESR branch, and if possible even the 78ESR branch to allow geckodriver sooner than later to make use of the new technique.

2. Update the Marionette client and harness code to handle the scenario when `port=0` is requested by a consumer. We should still keep `2828` as default to not cause incompatibilities with not yet updated consumers. Here we don't have to uplift patches. Here we do not have to care about backward compatibility (we do not push releases to pypi anymore) and can allow the code to ride the train. But the question is how we have to handle the Android scenario given that we do not have proper Android support for the harness (bug 1607210).

3. Update web-platform-tests to request port `0` from marionette client instead of finding a free port on its own, which is racy. And for sure looking for that file, and reading the port once it exists.

4. Update geckodriver to allow handling of port `0` (bug 1421766), whereby we would first need support for pulling files from the Android device (bug 1725622). By default we should keep port `2828` until we know it runs all stable.

5. At a later time consider using port `0` as default.

Lets discuss this topic in next week's triage meeting.

Given the discussion from comment 13 and comment 14 lets follow the approach by using a file in the profile directory to indicate the port as used by Marionette. It's actually backed by our partial CDP implementation where I'm about to land a patch that does the same thing (bug 1706581).

Because there is a bit more work to do here I'm going to transform this bug into a meta bug, and will update the dependency list for all the bits and pieces we have to take care. In general I'm thinking of the following strategy:

1. Start Marionette writing the file to the profile directory (bug 1735162) and maybe lets also include the feature for the BiDi implementation (bug 1749673). This patch should be uplifted to the 91ESR branch, and if possible even the 78ESR branch to allow geckodriver sooner than later to make use of the new technique.

2. Update the Marionette client and harness code to handle the scenario when `port=0` is requested by a consumer (bug 1750630). We should still keep `2828` as default to not cause incompatibilities with not yet updated consumers. Here we don't have to uplift patches. Here we do not have to care about backward compatibility (we do not push releases to pypi anymore) and can allow the code to ride the train. But the question is how we have to handle the Android scenario given that we do not have proper Android support for the harness (bug 1607210).

3. Update web-platform-tests to request port `0` from marionette client instead of finding a free port on its own, which is racy. And for sure looking for that file, and reading the port once it exists.

4. Update geckodriver to allow handling of port `0` (bug 1421766), whereby we would first need support for pulling files from the Android device (bug 1725622). By default we should keep port `2828` until we know it runs all stable.

5. At a later time consider using port `0` as default.

Lets discuss this topic in next week's triage meeting.

Given the discussion from comment 13 and comment 14 lets follow the approach by using a file in the profile directory to indicate the port as used by Marionette. It's actually backed by our partial CDP implementation where I'm about to land a patch that does the same thing (bug 1706581).

Because there is a bit more work to do here I'm going to transform this bug into a meta bug, and will update the dependency list for all the bits and pieces we have to take care. In general I'm thinking of the following strategy:

1. [Done] Start Marionette writing the file to the profile directory (bug 1735162) and maybe lets also include the feature for the BiDi implementation (bug 1749673). This patch should be uplifted to the 91ESR branch, and if possible even the 78ESR branch to allow geckodriver sooner than later to make use of the new technique.

1. Update the Marionette client and harness code to handle the scenario when `port=0` is requested by a consumer (bug 1750630). We should still keep `2828` as default to not cause incompatibilities with not yet updated consumers. Here we don't have to uplift patches. Here we do not have to care about backward compatibility (we do not push releases to pypi anymore) and can allow the code to ride the train. But the question is how we have to handle the Android scenario given that we do not have proper Android support for the harness (bug 1607210).

1. Update web-platform-tests to request port `0` from marionette client instead of finding a free port on its own, which is racy. And for sure looking for that file, and reading the port once it exists.

1. [Done] Update geckodriver to allow handling of port `0` (bug 1421766), whereby we would first need support for pulling files from the Android device (bug 1725622). By default we should keep port `2828` until we know it runs all stable.

1. At a later time consider using port `0` as default.

Lets discuss this topic in next week's triage meeting.

Given the discussion from comment 13 and comment 14 lets follow the approach by using a file in the profile directory to indicate the port as used by Marionette. It's actually backed by our partial CDP implementation where I'm about to land a patch that does the same thing (bug 1706581).

Because there is a bit more work to do here I'm going to transform this bug into a meta bug, and will update the dependency list for all the bits and pieces we have to take care. In general I'm thinking of the following strategy:

1. [Done] Start Marionette writing the file to the profile directory (bug 1735162) and maybe lets also include the feature for the BiDi implementation (bug 1749673). This patch should be uplifted to the 91ESR branch, and if possible even the 78ESR branch to allow geckodriver sooner than later to make use of the new technique.

1. Update the Marionette client and harness code to handle the scenario when `port=0` is requested by a consumer (bug 1750630). We should still keep `2828` as default to not cause incompatibilities with not yet updated consumers. Here we don't have to uplift patches. Here we do not have to care about backward compatibility (we do not push releases to pypi anymore) and can allow the code to ride the train. But the question is how we have to handle the Android scenario given that we do not have proper Android support for the harness (bug 1607210).

1. Update [web-platform-tests to request port `0` from marionette client](https://bugzilla.mozilla.org/show_bug.cgi?id=1753589) instead of finding a free port on its own, which is racy. And for sure looking for that file, and reading the port once it exists.

1. [Done] Update geckodriver to allow handling of port `0` (bug 1421766), whereby we would first need support for pulling files from the Android device (bug 1725622). By default we should keep port `2828` until we know it runs all stable.

1. At a later time consider using port `0` as default.

Lets discuss this topic in next week's triage meeting.