[Feature]: Allow to configure the protocol (`juggler` or `webDriverBiDi`) when launching the browser

[whimboo]

🚀 Feature Request

Now that WebDriver BiDi implements many of the requirements needed by Playwright, it would be great to see early adoption from users. Real-world feedback would be invaluable in helping us prioritize future API additions and enhancements.

I recently attempted to migrate another project from using Firefox with Juggler to WebDriver BiDi. However, it failed when trying to import _bidiFirefox from the playwright module. Besides the import issue itself, the use of the underscore prefix (_bidiFirefox) is also problematic. It typically indicates an internal or non-public API, which makes its usage feel unsupported or fragile.

Would it be possible to introduce a more stable and ergonomic way to choose between Juggler and WebDriver BiDi, perhaps via the launch options? For example, a protocol option could be added, allowing values like juggler (default) or webdriverBiDi. Internally, this would determine whether the firefox or _bidiFirefox browser class is instantiated. But maybe there is another option preferred by you?

Example

No response

Motivation

This type of setup worked well for us during the experimental phase with Puppeteer and would likely improve usability and adoption here as well.

@yury-s what do you think?

[yury-s]

Discussed this in the team meeting today. Before we expose Bidi as a public API, we’d like a clearer picture of where support currently stands.

When we were adding WebKit and Firefox support, we relied on a dashboard showing the number of passing tests per browser, plus a breakdown of failing test files and their pass/fail counts. That visibility helped identify which areas were still unsupported.

For Bidi, the best signal we have right now is the raw test output (e.g. 3176 passed out of 4182). While that points to 1k+ failures, it doesn’t show which components are affected. I know you’ve tracked this in docs/spreadsheets before, so you probably already have good insights.

Could you set up a dashboard for Bidi Firefox that shows current

• passing / failed / skipped (e.g. due to timeout) / total
• breakdown of failures by test file

That way we can see what’s missing and if it’s ready to go public.

[whimboo]

Discussed this in the team meeting today. Before we expose Bidi as a public API, we’d like a clearer picture of where support currently stands.

@yury-s, thank you for the feedback! So lets get on par to see at which state BiDi can be considered a public protocol for Playwright. Do you have specific guidelines / rules for that, like say are you differentiating between officially supported protocols and experimental ones? Or is it all the same for you?

When we were adding WebKit and Firefox support, we relied on a dashboard showing the number of passing tests per browser, plus a breakdown of failing test files and their pass/fail counts. That visibility helped identify which areas were still unsupported.

Could you set up a dashboard for Bidi Firefox that shows current

* passing / failed / skipped (e.g. due to timeout) / total

* breakdown of failures by test file

This sounds like a good idea. Right now we only track the numbers in the Playwright via WebDriver BiDi Google document and spreadsheet, but having an automated way to update the current status would be kinda great. When you say that you were using a dashboard in the past, is that still accessible and could be adapted for WebDriver BiDi? It would be faster to setup compared to writing a new one from scratch.

For Bidi, the best signal we have right now is the raw test output (e.g. 3176 passed out of 4182). While that points to 1k+ failures

Hm, where do you have those numbers from? From the daily CI runs we currently have:

2025-09-15: 3246 / 3852 passed (42min) - 221 skipped

This means only about 600 tests are not passing at the moment, which is 60% compared to your provided numbers. Or did you consider to include more tests beside those we originally set and tracked until now?

, it doesn’t show which components are affected. I know you’ve tracked this in docs/spreadsheets before, so you probably already have good insights.

I've spent some time to collect the information as best as I could and added the API: WebDriver BiDi sheet to the Google spreadsheet. Could you please take a look and check the following items?

1. Do I miss some important API or are some of them as listed not required (I marked some with question marks where I'm not sure - maybe you can add a comment with an explanation and tick of the checkbox of the Playwright wanted column?)
2. Are the priorities set correctly? Feel free to adjust as you think it is important. We are going to plan our next milestone soon so it would be good to know where our focus should be next.

Thanks!

[yury-s]

@yury-s, thank you for the feedback! So lets get on par to see at which state BiDi can be considered a public protocol for Playwright. Do you have specific guidelines / rules for that, like say are you differentiating between officially supported protocols and experimental ones? Or is it all the same for you?

Playwright doesn’t distinguish between different “protocols” for driving the same browser today, those are internal details. We’d rather not put that choice on users.

We also don’t have strict rules for when something is ready for public. In the past, when adding support for Firefox and WebKit, we used dashboards comparing feature parity across browsers, and the decision came down to common sense. The API surface has grown since then, so many smaller features aren’t as critical. A dashboard that groups failing tests by component (per-file granularity should be fine) is still the best way to judge maturity. Core interactions (page navigation, selectors, mouse/keyboard input) are essential, while some of the niche APIs (CSP bypass, geolocation emulation, etc.) could be marked “not yet supported.”

What we can do is to introduce (initially hidden as we do today, then experimental, eventually public) new channels for Firefox, similar to the ones for Chrome/Edge. The channels are essentially existing 'moz-firefox', 'moz-firefox-beta' and 'moz-firefox-nightly'. The users can opt into the them and use Bidi to connect to the official Firefox builds. Since most of the Bidi code lives in the Mozilla repo, and we can’t patch it as quickly as Playwright-owned code (getting consensus from the Firefox engineers and the code reviews, in more complex cases passing it through the spec, etc.), it makes sense for the Firefox team to own those channels. This would avoid Playwright being blocked by other teams'/committees reaction time, staffing, or approval processes when quick turnaround is needed, and ensures Bidi has a single clear owner.

By default we’d continue shipping Juggler with our bundled Firefox build to maintain the current support guarantees. Over time, when Firefox Bidi implementation matures, the adoption grows and we can be confident that incoming bugs affecting Firefox Bidi are fixed in a timely fashion, we can revisit switching the default implementation from Juggler to Bidi.

How does that sound to you?

When you say that you were using a dashboard in the past, is that still accessible and could be adapted for WebDriver BiDi? It would be faster to setup compared to writing a new one from scratch.

The source code lives here https://github.com/aslushnikov/isplaywrightready. It had been written before we implemented our own test runner with its reporting APIs. It should be much easier to produce the similar data with Playwright today. I'd not look at the old code much and just vibe code a new dashboard from scratch.

This means only about 600 tests are not passing at the moment, which is 60% compared to your provided numbers. Or did you consider to include more tests beside those we originally set and tracked until now?

You are right, I looked at the total number of our Firefox tests with Juggler. You numbers for the BiDi (moz-firefox-nightly) bot are more accurate, what I see is:

3852 total
 385 failed
 221 skipped
3246 passed

I remember that some of the Firefox tests, that have been excluded from the original suite for Bidi, cover Playwright functionality that is not browser specific. Shouldn't they be mostly passing now that more features have been supported? It's important for the users that the trace viewer/inspector work with Firefox Bidi. If the trace-viewer tests are failing because of non-implemented pieces of the API, it's a strong signal that the API is of high priority.

I've spent some time to collect the information as best as I could and added the API: WebDriver BiDi sheet to the Google spreadsheet. Could you please take a look and check the following items?

From what I see, I believe "Actions: Scroll to element" corresponds to scrollIntoViewIfNeeded and is of top priority, as it used in all actions. The rest look okay, having a dashboard with the failing tests would help to identify what's missing and refine the list.

[whimboo]

We also don’t have strict rules for when something is ready for public. In the past, when adding support for Firefox and WebKit, we used dashboards comparing feature parity across browsers, and the decision came down to common sense. The API surface has grown since then, so many smaller features aren’t as critical. A dashboard that groups failing tests by component (per-file granularity should be fine) is still the best way to judge maturity. Core interactions (page navigation, selectors, mouse/keyboard input) are essential, while some of the niche APIs (CSP bypass, geolocation emulation, etc.) could be marked “not yet supported.”

We are going to explore a solution for a dashboard so that it's easier to examine which APIs, that are required, are still missing or haven't been fully implemented yet. We will let you know when there is a dashboard available.

What we can do is to introduce (initially hidden as we do today, then experimental, eventually public) new channels for Firefox, similar to the ones for Chrome/Edge. The channels are essentially existing 'moz-firefox', 'moz-firefox-beta' and 'moz-firefox-nightly'.

That seems fine. Based on the fact that those channels are hidden as of today, is there a way for clients using Playwright as framework to make use of them? I tried that but it fails with Unsupported firefox channel "moz-firefox". I assume that's expected. When I'm trying to use _bidiFirefox it fails because there is no such exported name. Would it work when the support of the channels is marked as experimental? Which expectations do you then have for experimental, and public? For us it would be good to get some feedback from actual users so that we can do our planning more based on actual users needs as just on the assumption of unit tests.

You are right, I looked at the total number of our Firefox tests with Juggler. You numbers for the BiDi (moz-firefox-nightly) bot are more accurate, what I see is:

3852 total
 385 failed
 221 skipped
3246 passed

Are you actually uploading results for Firefox with Juggler as artifacts as well on a daily basis? Or is that something you aren't doing right now? If might be good to as well compare the results from Juggler with BiDi.

I remember that some of the Firefox tests, that have been excluded from the original suite for Bidi, cover Playwright functionality that is not browser specific. Shouldn't they be mostly passing now that more features have been supported? It's important for the users that the trace viewer/inspector work with Firefox Bidi. If the trace-viewer tests are failing because of non-implemented pieces of the API, it's a strong signal that the API is of high priority.

Yes, most of these tests are passing now, and we got them enabled in the meantime. Some of them are still failing but we have them on our list now.

I've spent some time to collect the information as best as I could and added the API: WebDriver BiDi sheet to the Google spreadsheet. Could you please take a look and check the following items?

From what I see, I believe "Actions: Scroll to element" corresponds to scrollIntoViewIfNeeded and is of top priority, as it used in all actions. The rest look okay, having a dashboard with the failing tests would help to identify what's missing and refine the list.

For Scroll to Element there are two different scenarios. One you already mentioned for Actions, so that a given action in the chain can scroll to the element first, before interacting with it. The other scenario is a global Scroll into View feature, which for the time being could be implemented with a script evaluation call if needed. Which of those two are you referring to with a high priority?

[yury-s]

That seems fine. Based on the fact that those channels are hidden as of today, is there a way for clients using Playwright as framework to make use of them? I tried that but it fails with Unsupported firefox channel "moz-firefox". I assume that's expected. When I'm trying to use _bidiFirefox it fails because there is no such exported name. Would it work when the support of the channels is marked as experimental? Which expectations do you then have for experimental, and public? For us it would be good to get some feedback from actual users so that we can do our planning more based on actual users needs as just on the assumption of unit tests.

I think we should be able to update the code to make playwright.firefox work with the new Firefox channels, similar to how it works for Chrome and MSEdge on playwright.chromium. Ideally we shouldn't need separate playwright._bidiFirefox (it was more convenient to have it separate for the initial implementation), even if under the hood it uses 2 different implementations.

Are you actually uploading results for Firefox with Juggler as artifacts as well on a daily basis? Or is that something you aren't doing right now? If might be good to as well compare the results from Juggler with BiDi.

We do upload test results to our internal flakiness dashboard for tracking general health of the project. It does provide way more detailed view than what is needed for comparing feature parity of Juggler v Bidi though. You can add a step that would upload juggler results to another place for comparison.

For Scroll to Element there are two different scenarios. One you already mentioned for Actions, so that a given action in the chain can scroll to the element first, before interacting with it. The other scenario is a global Scroll into View feature, which for the time being could be implemented with a script evaluation call if needed. Which of those two are you referring to with a high priority?

I'm talking about scrolling the element before an action, as this is what we do before each mouse interaction. I'm not sure how global Scroll into View is different, but if you say it could be scripted then it's likely lower priority.

[whimboo]

That seems fine. Based on the fact that those channels are hidden as of today, is there a way for clients using Playwright as framework to make use of them? I tried that but it fails with Unsupported firefox channel "moz-firefox". I assume that's expected. When I'm trying to use _bidiFirefox it fails because there is no such exported name. Would it work when the support of the channels is marked as experimental? Which expectations do you then have for experimental, and public? For us it would be good to get some feedback from actual users so that we can do our planning more based on actual users needs as just on the assumption of unit tests.

I think we should be able to update the code to make playwright.firefox work with the new Firefox channels, similar to how it works for Chrome and MSEdge on playwright.chromium. Ideally we shouldn't need separate playwright._bidiFirefox (it was more convenient to have it separate for the initial implementation), even if under the hood it uses 2 different implementations.

That would be great! Do you have a rough idea of when this could be done? Also, I’m still a bit unsure about whether this depends on having the full dashboard in place and the requested test coverage for certain not-yet-fully-implemented APIs. Is that a hard requirement even for offering experimental support? Or would partial coverage be acceptable in that case? We would really be interested to get user reports if possible.

Are you actually uploading results for Firefox with Juggler as artifacts as well on a daily basis? Or is that something you aren't doing right now? If might be good to as well compare the results from Juggler with BiDi.

We do upload test results to our internal flakiness dashboard for tracking general health of the project. It does provide way more detailed view than what is needed for comparing feature parity of Juggler v Bidi though. You can add a step that would upload juggler results to another place for comparison.

Thanks! We will discuss internally if we want to use it.

For Scroll to Element there are two different scenarios. One you already mentioned for Actions, so that a given action in the chain can scroll to the element first, before interacting with it. The other scenario is a global Scroll into View feature, which for the time being could be implemented with a script evaluation call if needed. Which of those two are you referring to with a high priority?

I'm talking about scrolling the element before an action, as this is what we do before each mouse interaction. I'm not sure how global Scroll into View is different, but if you say it could be scripted then it's likely lower priority.

One possible path forward would be to implement this directly in Playwright using plain script evaluation, rather than relying on a dedicated BiDi API. So the previously mentioned Playwright API would still be exposed to clients, just with a different underlying mechanism. If that approach is acceptable, we could look into supporting it for both Firefox and Chrome.

[yury-s]

That would be great! Do you have a rough idea of when this could be done? Also, I’m still a bit unsure about whether this depends on having the full dashboard in place and the requested test coverage for certain not-yet-fully-implemented APIs. Is that a hard requirement even for offering experimental support? Or would partial coverage be acceptable in that case? We would really be interested to get user reports if possible.

I will work on it, don't remember what the blockers were that made us use _bidiFirefox instead. We don't need to block this on the dashboard and the readiness criteria. We can add the new channel without advertising it in the docs for now, it should allow to collect the user feedback sooner. For the official channel (even if experimental) with the docs, it'd be nice to have the dashboard to be transparent on what is ready and what is not.

One possible path forward would be to implement this directly in Playwright using plain script evaluation, rather than relying on a dedicated BiDi API. So the previously mentioned Playwright API would still be exposed to clients, just with a different underlying mechanism. If that approach is acceptable, we could look into supporting it for both Firefox and Chrome.

You can try and see if that works, maybe you can leverage some of the Firefox APIs to avoid the native part altogether. There were some difficulties around minimal offsets and display:contents, probably something else, but we should have tests for that. If the user land implementation doesn't work for some of the edge cases, you can still start with that. I'd not bother with reimplementing Chrome as CDP supports the scrolling with a native command.

[yury-s]

That would be great! Do you have a rough idea of when this could be done?

After #37696 the same playwright.firefox instance can be used to connect to Firefox over bidi. Please give it a try, there might be some regressions.

[hbenl]

@yury-s FYI: We've created a dashboard for the Playwright BiDI tests.
You can filter out test files that you're not interested in by using the gear icon in the top left and bookmark the filtered view.
Clicking on one of the bars in the chart takes you to a view for that test run and clicking on the "Diff" link in that view shows the changed test results compared to the previous test run.

[yury-s]

Nice! A few thoughts:

• there are some failing click tests, we'd consider them a top priority
• other interaction tests like mouse, drag, keyboard also cover user interactions and would be the top priority for fixing before opening this to a broader audience. Most of the test cases are based on the client reports, so we know that they are actually important for real world scenarios even if they look like unlikely edge cases.
• network events and interception are the next big things there, it'd be nice to have them fixed
• it'd be easier to assess failures in each area/file if
  • each file had a number of failing/total tests and
  • could be expanded to see which tests are failing
• It doesn't make much sense to have Firefox and Chrome on the same dashboard. If we want to compare, it should be Firefox Bidi vs Firefox juggler.

[hbenl]

* it'd be easier to assess failures in each area/file if
  * each file had a number of failing/total tests and

they're shown in the tooltip when hovering over the results bar

  * could be expanded to see which tests are failing

I've just added this