Closed Bug 1749673 Opened 3 years ago Closed 3 years ago

[Desktop] Read WebDriver BiDi port from WebDriverBiDiActivePort file within the Firefox profile directory

Categories

(Testing :: geckodriver, task, P2)

Product:
Testing
Component:
geckodriver
Type:
task
Points:
2

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: whimboo, Unassigned)

References

(Blocks 1 open bug)

Details

Similar to CDP (bug 1706581) and Marionette (bug 1735162) we should do that for BiDi. Hereby I wonder if we should use a separate file or combine it with Marionette to lets say have a single file with the following contents:

BiDi: localhost:9992
Marionette: localhost:2828

If we wanna do that we should do it now before we actually make use of it via bug 1240830.

Otherwise we will just put localhost:9992 in a WebDriver BiDi specific file within the profile.

We discussed today and agreed to have separate files. It will actually be hard to write a single file given that both Marionette and WebDriver BiDi are different components and can be enabled/disabled individually. Maybe there is some cost to create/write to a second file but it's only happening when --remote-debugging-port has been specified.

Whiteboard: [webdriver:triage]
Blocks: 1240830
No longer blocks: 1240830
See Also: → 1240830
Blocks: 1751844

Given that this feature would be helpful for Selenium integration lets try to get it uplifted to 97 beta if still possible.

Assignee: nobody → hskupin
Status: NEW → ASSIGNED
status-firefox97: --- → affected
status-firefox98: --- → affected
status-firefox-esr91: --- → wontfix
Priority: P3 → P2
Whiteboard: [bidi-m3-mvp]
No longer blocks: 1751844
Depends on: 1751844
Assignee: hskupin → nobody
Status: ASSIGNED → NEW
status-firefox97: affected → ---
status-firefox98: affected → ---
status-firefox-esr91: wontfix → ---
Component: WebDriver BiDi → geckodriver
Priority: P2 → P3
Product: Remote Protocol → Testing
Summary: Write WebDriver BiDi connection details to "WebDriverBiDiActivePort" file in the profile directory → Read WebDriver BiDi port from WebDriverBiDiActivePort file within the Firefox profile directory
Depends on: 1421766
See Also: 1706581, 1735162, 1240830 →

This is for Desktop right now. Android will follow-up later on.

Points: --- → 2
Priority: P3 → P2
Summary: Read WebDriver BiDi port from WebDriverBiDiActivePort file within the Firefox profile directory → [Desktop] Read WebDriver BiDi port from WebDriverBiDiActivePort file within the Firefox profile directory

I was thinking more about that issue and actually there is nothing to do for us on geckodriver's site. Let me explain why:

geckodriver itself allows consumers to opt-in to WebDriver BiDi by specifying the webSocketUrl capability. Remote Agent will then create the WebSocket server on the given port, which Marionette includes in the returned webSocketUrl capability. Given that this is returned to consumers of geckodriver they are already aware of the correct port.

The only problem I could foresee is with Android. Given that the connection is not a plain socket connection and contains the host header (including the port), the adb forward has to use the same port on both sides (host and device). As such using a port of 0 could create a race condition if the port is already taken on the host side. But that's clearly a separate issue.

In case we all agree I would close this bug and file another one for the Android forwarding case.

Whiteboard: [bidi-m3-mvp] → [bidi-m3-mvp][webdriver:triage]

As discussed in the meeting we will close this bug and I'm going to file a new bug for Android.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
Whiteboard: [bidi-m3-mvp][webdriver:triage] → [bidi-m3-mvp]
Whiteboard: [bidi-m3-mvp]
You need to log in before you can comment on or make changes to this bug.