Thank you!!! I worked a bit in the past on maintaining a e2e web app integration test suite, testing on both Chrome and Firefox, and one of the most annoying things in the legacy WebDriver protocol was behavior differences when running the tests on different browsers. Or tests breaking after a browser update. And the new-er W3C WebDriver protocol didn’t solve this problem (and maybe actually even introduced more problems). I think the biggest contribution of Playwright is that Microsoft is putting in the leg work to make it work consistently across all the browsers (and that it works with their new versions). Sure, it’s not exactly 100% Firefox or Safari (they maintain forks) but I think it should be good enough to test most important functionality across all browsers.

Related, the W3C people have been working on another huge specification in WebDriver BiDi, we’ll see how well supported that one will be… And fresh off the press, with a 1.0 version already released (in Gleam style, where they intentionally discourage library authors from publishing 0.x versions so that APIs are well thought out from the start and libraries are not stuck in that chaotic pre-1.0 world) there’s now a Gleam library called butterbee for working with WebDriver BiDi.

What I’m less sure about is the API. Happy to hear your thoughts!

That probably goes without saying, but I think all of the hound, wallaby and now also butterbee could be an inspiration here. Personally I like your approach of having extracted the lower-level bits from phoenix_test_playwright, I think it would be best to focus on the protocol itself and a “client library” alone, and leave the higher level testing helpers and Ecto/Phoenix integration conveniences to other libraries building on top of it. For Wallaby, I know @aaronrenner extracted web_driver_client having that approach in mind