Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] How does Puppeteer's new Firefox support affect Playwright? #1765

Closed
celeryclub opened this issue Apr 13, 2020 · 2 comments
Closed

Comments

@celeryclub
Copy link
Contributor

Hey team. I hope all is well.

I'm curious how the release of Puppeteer 2.1.0 affects Playwright. It appears that since puppeteer/puppeteer#5137 was merged, Firefox support has changed - "Puppeteer can now talk to a real, unpatched Firefox binary (as opposed to the old Juggler-based approach)".

Does this affect Playwright's approach in any way? Are you planning to transition to the unpatched binary like Puppeteer has done?

Thanks for addressing all my questions/issues. :)

@pavelfeldman
Copy link
Member

Disclaimer: I introduced CDP, started Puppeteer and currently work on Playwright. New Puppeteer maintainers and Firefox engineers would be better equipped to cover the Puppeteer part of the story.

Yes, Puppeteer can talk to a real, unpatched Firefox binary. This is a great achievement based on the Firefox teams's effort to support CDP in Firefox natively. We are excited about this progress, and will be happy to migrate to the CDP mode of operation when it is fully functional. Furthermore, we've met with the Firefox team recently and they were open to us upstreaming the native parts of Juggler that would make sense for the general browser automation.

There is a long road ahead though. CDP has a huge API surface and it'll take quite some time to get it done to the extent needed by Playwright. CDP is also dynamic - while working on Playwright, we changed it in the areas of permissions, geolocation, context and target management. So going after CDP is somewhat chasing a moving target. I ran Puppeteer tests against latest Firefox 77.0a1 and it currently passes less that a half of the tests. This is a great progress, but it gives a hint at the outstanding work. And that is just Puppeteer - since we forked Playwright, we added numerous capabilities for context-wide network routing, support for workers, dom isolated worlds, emulation of geolocation, timezone, locale, and many more. You can imagine that the Juggler protocol grew with it and now there is even more work ahead on the CDP front if we want parity.

It is also important to understand that unlike Firefox, WebKit is following the Chrome's debug protocol philosophy: instead of conforming to a standard, they shape their protocol after the WebKit specificity. That way they can be efficient at using this protocol in the Web Inspector while they leave augmenting it to the external Playwright driver. It means that even if/when Firefox supports the entirety of CDP, Playwright would still need to maintain non-CDP connection to WebKit.

All in all, I would say that Playwright has a different philosophy when it comes to the cross-browser support. We commit to passing the compatibility test suite of a thousand tests uniformly against Chromium, WebKit & Firefox. We commit to doing that even if we need to maintain the fork of the browser in the near term. That's a relatively small price to pay for a modern and capable testing solution we deliver today. We hope that our efforts will help shaping the protocols of the future, while providing all the benefits of them today, similarly how it happened with CDP and Puppeteer.

@celeryclub
Copy link
Contributor Author

This is a very thoughtful and detailed response. I really appreciate you taking the time to write this up. I have a much clearer understanding of the present state of CDP and what the future plans are for Playwright. Thanks a million! 💰

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants