[🐛 Bug]: DevTools Functionality is Broken for Firefox 97 in Java

[titusfortner]

What happened?

Firefox now requires an empty origin header for websockets, and Netty sends one by default: netty/netty#9673

How can we reproduce the issue?

FirefoxDriver driver = new FirefoxDriver();
DevTools devTools = driver.getDevTools();

Relevant log output

JavaScript error: chrome://remote/content/server/WebSocketHandshake.jsm, line 117: Error: The handshake request has incorrect Origin header http://localhost:50021
Feb 09, 2022 1:45:20 PM org.openqa.selenium.remote.http.WebSocket$Listener onError
WARNING: Invalid Status code=400 text=Bad Request
java.io.IOException: Invalid Status code=400 text=Bad Request
	at org.asynchttpclient.netty.handler.WebSocketHandler.abort(WebSocketHandler.java:92)
	at org.asynchttpclient.netty.handler.WebSocketHandler.handleRead(WebSocketHandler.java:118)
	at org.asynchttpclient.netty.handler.AsyncHttpClientHandler.channelRead(AsyncHttpClientHandler.java:78)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:311)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:432)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
	at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:834)


org.openqa.selenium.remote.http.ConnectionFailedException: Unable to establish websocket connection to http://localhost:50021/devtools/browser/2857af35-3ab7-42f3-bdfa-efedc76ffba4

Operating System

MacOS Big Sur

Selenium version

Java 4.1.1

What are the browser(s) and version(s) where you see this issue?

Firefox 97

What are the browser driver(s) and version(s) where you see this issue?

Geckodriver 0.30.0

Are you using Selenium Grid?

n/a

[diemol]

AsyncHttpClient adds an origin header for WebSocket requests. Sadly, this is not configurable.
After chatting with @whimboo, Firefox will do a patch where a way to go around this will be added.
https://bugzilla.mozilla.org/show_bug.cgi?id=1750689

[asolntsev]

@diemol Don't we want to patch AsyncHttpClient or find a better alternative if it's not supported anymore?

[whimboo]

We are sorry about this regression. @titusfortner can you please explain the severity for it? In the short term we could have a patch that only enables these checks for WebDriver BiDi and leaves CDP alone until we are clear that it's working correctly and doesn't cause regressions for clients. We could uplift to Firefox 98 beta. How helpful would that be for you?

Further how could we prevent these issues in the future? Do you have any CI jobs for Selenium that would at least run the set of existing tests for at least a Firefox beta? In such a case we would have the time to patch and uplift a regression to not break users on releases.

[titusfortner]

I don't think devtools methods are being used for Firefox, yet. This was only flagged because of how selenium code elsewhere assumed there was going to be a CDP session and threw an unnecessary error.

Yeah, leaving CDP alone until we figure things out with bidi makes sense to me.

We can take a look at selenium Java tests, should be easy to add a github actions toggle for nightly if we want.

[whimboo]

I don't think devtools methods are being used for Firefox, yet. This was only flagged because of how selenium code elsewhere assumed there was going to be a CDP session and threw an unnecessary error.

The Java bindings use our CDP implementation for logging events, so what does devtools in this case actually refer to?

Yeah, leaving CDP alone until we figure things out with bidi makes sense to me.

Both CDP and WebDriver BiDi make use of the same WebSocket code. As such we had this overlap and accident regression. We will introduce a patch which will disable the origin check if BiDi is not enabled (beta/release) until the final patch for host/origin opt-in has been landed.

We can take a look at selenium Java tests, should be easy to add a github actions toggle for nightly if we want.

That would be amazing! Thanks a lot.

[titusfortner]

I only mean to say that based on various data points, the functionality we provide (CDP) doesn't seem to be getting a lot of use, yet.

Hmm, doesn't look like it's easy to set up Firefox Nightly on Github actions. Can do a dev edition with this action https://github.com/browser-actions/setup-firefox

[whimboo]

Having a job that runs a developer edition build would be also great. That gives us enough time to fix regressions while the code is on beta.

Nevertheless of the usage data we will push a small patch to beta. So folks using the logging feature might have to use beta for a while.

[titusfortner]

Yes, I've verified if we force it to use Dev Edition here: https://github.com/titusfortner/selenium/pull/39/files

We get failures in Firefox 98 that we aren't getting in Firefox 96 (doesn't look like by default Github is using most recent Firefox): https://github.com/titusfortner/selenium/runs/5189467447?check_suite_focus=true#step:10:12642

The way our java.yml workflow is set up, though, it won't be easy to toggle between Firefox versions.

[titusfortner]

Ok, got it working. We're now running Firefox latest and latest-devedition with Java on Github Actions, so we should get a heads up.

Since there's nothing more we can do on the Selenium side, I'm closing this issue.

[github-actions]

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.