User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

Navigate to https://ipv6canvas.tugzrida.xyz/

Actual results:

Other than info in the area at top, the IPv6 canvas does not render

Expected results:

The canvas should render and the info on top be partially transparent.

https://ipv6canvas.tugzrida.xyz/ does not work in Nightly (tried a new profile), nor in Beta.

https://ipv6canvas.tugzrida.xyz/ works in Firefox Release and in Chrome (Stable) and Edge (release).

gui-mozregression stopped at:

2023-02-07T12:21:15.570000: DEBUG : Found commit message:
Bug 1774572 - Handle the case when the Http/2 server doesn't support websocket, r=edgul

Differential Revision: https://phabricator.services.mozilla.com/D165275

2023-02-07T12:21:15.570000: DEBUG : Did not find a branch, checking all integration branches
2023-02-07T12:21:15.585000: INFO : The bisection is done.
2023-02-07T12:21:15.585000: INFO : Stopped

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Canvas2D' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

I can reproduce the issue on Nightly111.0a1 and Firefox110.0RC1 Windows10.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bd0b85553044e559f3d3e60b1ab61efab0956640&tochange=6c7e9cf2f9863eaecb19cbfa0fcb45e2bdc6f10e

:kershaw, since you are the author of the regressor, bug 1774572, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

This is actually the same as bug 1807474.
The reason why Chrome works is that it doesn't connect to the wss server with Http/2, it uses Http/1.1, but Firefox tries to connect to the same server with Http/2.

Note that this is a long standing issue, not a recent regression. I've tested with esr78 and this issue already exists. It's just that we re-enabed websocket over h2 in bug 1774572, so we hit this issue.

I think I should mention this in case someone was testing against this site:

Site https://ipv6canvas.tugzrida.xyz/ has stopped its operation with the message, "That's all folks! Thanks to everyone who played in good faith ☺️"

Noting chrome only does WebSocket over HTTP/2 if:

• there is already an open HTTP/2 connection and
• it has already received a SETTINGS frame from the server on that connection with SETTINGS_ENABLE_CONNECT_PROTOCOL = 1

Set release status flags based on info from the regressing bug 1774572

Note that I am currently working on the tests for this in Bug 1800529

Status: Some rough tests complete, moving into implementation changes.

Quick update:
I've added a pref to enable/disable websocket default to h1 (When no existing h2 connections) and put an initial implementation behind it.
After adding an additional test to validate, there appears to be an issue with the implementation so I am currently debugging this.

Additionally:
Testing the the current implementation against the previous tests reveals that there will be another implementation change necessary to enable a fallback to h1.1 when we have h2 connection with an h2 server that does not support h2ws. Still investigating this.

WebSocket WG is discussing ways to simplify how the client can find out if the server supports WS over HTTP/2. We still need this patch for fallback, but it is not P1.

Moved back into next since it has been on my backburner for a while