feat: ability to use selenium settings via launch options#24073
feat: ability to use selenium settings via launch options#24073DudaGod wants to merge 1 commit intomicrosoft:mainfrom
Conversation
c061d54 to
88c7182
Compare
| * Custom headers to pass into every request | ||
| */ | ||
| headers?: { [key: string]: string; }; | ||
| }, |
There was a problem hiding this comment.
I don't understand why build script remove my typings which must be there
|
"tests 1" report. |
|
Selenium grid support is a highly experimental feature guarded by the environment flags in Playwright. It was added there to encourage experimentation and see if Selenium grid can be used as a generic browser backend for Playwright. It is unlikely that we'll be releasing it out of experimental though, so we can't introduce any APIs or configuration options that would be referencing it. Furthermore, the latest signals from the Selenium grid are that it positions itself as a Selenium grid, not a browser grid and as such it should not be used by Playwright (see SeleniumHQ/selenium#11590 (comment)). So we are going to be unenrolling this experiment gragually. |
This is strange, because in the documentation there is nothing about the fact that this is an experimental feature.
But they said that they are ready for collaboration. Why we can't just support BiDi protocol when it will be released instead of just removing everything related to selenium? |
For what? To lose your clients? This functionality greatly expands the possibilities of your tool. Our team can implement this feature ourselves (in pw or in selenium). We only need confirmation from your team that you will not remove this functionality |
|
@pavelfeldman can you answer our questions? |
We should have made it more clear that support for Selenium is experimental. We introduced it silently, but should have added a better disclaimer for it, we'll fix that.
BiDi is not a CDP replacement, so you can't say "make Playwright work with BiDi". It would take several years of engineering work done by the browser vendors, counting from the time when BiDi considers supporting feature set sufficient for Playwright, if that even happens. So we are talking about ~5-10 years timeframe, if ever.
As long as Selenium Grid exposes CDP in a generic manner, we should be able to keep Playwright working against it. But given the public plans to remove CDP, we can't suggest our users to onboard the stack that is likely facing a dead end. So given their plans, we are hesitant growing the feature set, accepting patches like this, because it'll be sending the wrong signal to the customers. Did you look into implementing Playwright Grid instead (and open sourcing it)? I know that Moon folks did something like that, running Playwright Servers instead of the Selenium Grid Agents should be straightforward. |
|
@pavelfeldman I think it is unwise to reject this feature. Even though the Selenium community claims that they will replace it with BiDi in the future, I still doubt that they will give up CDP completely. Even they dare to do so, there are other Selenium compatible solutions like Selenoid and selenium-federation to support this feature. I believe that as long as someone needs it, there will definitely be solutions to support it. |
|
Removing CDP from Selenium Grid will take at least 1-2 years. As I mentioned in the comment referenced, the Selenium project is always open to collaboration. If leaving CDP enabled in Selenium Grid is a first step to enabling collaboration between projects, we can look into it. We would just love to hear from the Playwright folks and have a chat. |
What's done
Implement ability to specify selenium settings via launch options in pwt config or standalone script. It will allow to configure the project more conveniently and in one place without the need to use environment variables. For backwards compatibility, I didn't delete env vars and give them the highest priority (to be able to redefine some options in CI for example).
What problems does it solve
SELENIUM_REMOTE_CAPABILITIES);