[🐛 Bug]: WebSockets broken since 4.5.0 #11590
Comments
|
@wodyjowski, thank you for creating this issue. We will troubleshoot it as soon as we can. Info for maintainersTriage this issue by using labels.
If information is missing, add a helpful comment and then
If the issue is a question, add the
If the issue is valid but there is no time to troubleshoot it, consider adding the
If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C),
add the applicable
After troubleshooting the issue, please add the Thank you! |
|
|
There's a reason we closed that issue— we didn't get enough information to continue investigating. You recreated it, but did not provide any additional info. If we don't get a way we can reproduce this, we'll end up closing this one as well. |
|
Hello @titusfortner.
Does it have to be written with Selenium?
I can confirm that the fix suggested by EndPositive in this comment fixes the problem. I have mentioned it in the existing issue opened with the playwright team:
I'm not sure who should be responsible for this. |
Yes, because we do not have related issues reported with Selenium code.
We do support the use cases around Selenium, there is no official integration between Selenium Grid and Playwright. It just seems they found a way to leverage the exposed websockets because for now Selenium uses CDP under the hood to serve some use cases. Nevertheless, given that Selenium relies on standards, the team is working with the Browser Testing and Tools Working Group to replace in the future the CDP integration with BiDi. So, even if the issue is fixed now with that workaround, it will break in the future again. All this is to say that we have been always open for collaboration with the Playwright team, if they want to contribute to fix this issue, we'd be happy to review the pull request. And ideally they want to contribute to BiDi, so this use case they offer to their users relies on standards and won't break in the future again. I will close this issue and when they open a PR, they can reference it as background. Thank you! |
|
@diemol @titusfortner example in .NET: https://github.com/wodyjowski/SeleniumIssue |
|
I think the jdk client is splitting huge messages to multiple smaller frames. The MessageInboundConverter should handle the This assumption is based on the netty javadoc and might be wrong. |
|
I see the return code 1002 in the logs, which says: So I am not sure if it is the browser endpoint closing the socket in an unexpected way. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
|
Just FYI, I left this comment wrt using Grid with Playwright. |
What happened?
Since 4.5.2 (i.e. JDK11 client), we've been experiencing an issue with the WebSocket. In this case, large messages sent over the WebSocket proxy (i.e. Selenium Hub + Selenium Node configuration), the receiver incorrectly assumes that the received frame is final. This results in a JSON decoding error in the string builder, which in turn results in the socket closing.
This is a copy-paste from #11408 as the issue still persists.
Running the grid with hub in version 4.5.0 fixes the issue:
I know that you don't support either Playwright or Puppeteer but it looks like an issue with general websocket communication.
How can we reproduce the issue?
Relevant log output
Operating System
Windows 11
Selenium version
Any version of selenium/hub > 4.5.0
What are the browser(s) and version(s) where you see this issue?
Any version of selenium/hub > 4.5.0
What are the browser driver(s) and version(s) where you see this issue?
Any version of selenium/hub > 4.5.0
Are you using Selenium Grid?
Any version of selenium/hub > 4.5.0
The text was updated successfully, but these errors were encountered: