1985231 - noisemonitoring.brussels - Firefox is not supported

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: Firefox 143.0

Steps to reproduce:

1. Navigate to: https://noisemonitoring.brussels/sara/sara6/#/sara6/home?site=BE
2. Dismiss the cookie banner and observe the page footer

Expected Behavior:
The page loads content

Actual Behavior:
Page logo is loaded and an unsupported pop-up is triggered in the page footer

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/173720

Comment 1

[Raul Bucata]

Attachment: Chr vs FF

Comment 2

[Sky Schubert [:skyschub]]

Still broken if I spoof as Chrome, and I see a bunch of failing requests to an MQTT endpoint. Let's have Networking look at it, maybe we can learn something.

Comment 3

[Andrew Creskey [:acreskey]]

Using Firefox 144 Nightly, user agent as Chrome.

These are the reported request failures:

XHRPOST
https://noisemonitoring.brussels/AuthApi/users/session
[HTTP/2 401  165ms]

XHRPOST
https://noisemonitoring.brussels/Sara6/Backend/SaraApi/tools/GetData
[HTTP/2 500  155ms]

In Firefox, for the session call I see a failure and then success (same behaviour as Chrome browser)
401 - Unauthorized https://noisemonitoring.brussels/AuthApi/users/session
200 - OK https://noisemonitoring.brussels/AuthApi/users/session

For the GetData request, in both Firefox and Chrome I see two successes
200 - OK https://noisemonitoring.brussels/Sara6/Backend/SaraApi/tools/GetData
200 - OK https://noisemonitoring.brussels/Sara6/Backend/SaraApi/tools/GetData
And then this failure for both.
500 Internal Server Error, "Key not found"

And then in Chrome the requests continue.

Without debugging how the site works, it's not clear to me what's preventing it from making more request in Firefox.

Comment 4

[Andrew Creskey [:acreskey]]

Interestingly enough, sometimes this site fails to load in Chrome as well (spinner persists on landing page).
edit: no, it does always appear to load in Chrome, although it may take up to a minute.

Comment 5

[Andrew Creskey [:acreskey]]

Disabling http/2, i.e. network.http.http2.enabled:false does allow the site to load in Firefox.

Comment 6

[Andrew Creskey [:acreskey]]

What's happening is that Chrome makes the websocket connection over http/1.1 whereas in Firefox we attempt to use http/2.

From Chrome har files:

         "url": "wss://mqtt.softech-service.com:9443/",
          "httpVersion": "HTTP/1.1",
          "headers": [

And in Firefox, I believe through what is HTTP/2 Extended CONNECT, we end up trying a series of connections that are all server terminated:

      {
        "startedDateTime": "2025-11-07T16:55:11.995-05:00",
        "request": {
          "bodySize": 0,
          "method": "GET",
          "url": "wss://mqtt.softech-service.com:9443/",
          "httpVersion": "HTTP/2",
          "headers": [
            {
              "name": "Host",
              "value": "mqtt.softech-service.com:9443"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:146.0) Gecko/20100101 Firefox/146.0"
            },
            {
              "name": "Accept",
              "value": "*/*"
            },
            {
              "name": "Accept-Language",
              "value": "en-CA,en-US;q=0.7,en;q=0.3"
            },
            {
              "name": "Accept-Encoding",
              "value": "gzip, deflate, br, zstd"
            },
            {
              "name": "Sec-WebSocket-Version",
              "value": "13"
            },
            {
              "name": "Origin",
              "value": "https://noisemonitoring.brussels"
            },
            {
              "name": "Sec-WebSocket-Protocol",
              "value": "mqtt"
            },
...

Comment 7

[Andrew Creskey [:acreskey]]

If I modify Http2Session::GetExtendedCONNECTSupport() to return ExtendedCONNECTSupport::NO_SUPPORT; then the site loads correctly in Firefox.
https://searchfox.org/firefox-main/rev/7f33a0cc184f6372c66281499063bda0f42f9c83/netwerk/protocol/http/Http2Session.cpp#4288-4295

I have very shallow understanding of Websockets, but maybe we want to fallback to HTTP/1.1 if the HTTP/2 connection fails?

Comment 8

[Kershaw Chang [:kershaw]]

I think this is a server-side issue (see Bug 1815545). The server negotiates HTTP/2 and advertises Extended CONNECT (SETTINGS_ENABLE_CONNECT_PROTOCOL), but WebSocket-over-HTTP/2 fails. We should contact the site to either disable HTTP/2 or stop advertising SETTINGS_ENABLE_CONNECT_PROTOCOL.

Comment 9

[Andrew Creskey [:acreskey]]

Agreed - the reason this works in Chrome is because they don't use Extended CONNECT for WebSockets.

Comment 10

[Andrew Creskey [:acreskey]]

This is hosted on Cloudflare, from what I see

< location: http://noisemonitoring.brussels/sara/PublicBE.html
< server: cloudflare