1972496 - run.claw.cloud - Stuck loading when accessing the terminal inside the web app

Status: NEW

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

Description

[Calin Tanase]

Environment:
Operating system: Windows 10
Firefox version: Firefox 139.0/141

Steps to reproduce:

1. Go to https://run.claw.cloud/
2. Click on "Get started" or "Get started for free"
3. Log in with your google or github account.
4. Create a workspace if you are first time user. (e.g. picked Germany as region and put a random name)
5. Click on "Terminal".
6. Observe the behavior.

Expected Behavior:
The terminal loads.

Actual Behavior:
Terminal is stuck loading.

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/162147

Comment 1

[Calin Tanase]

Attachment: FF vs Chrome.png

Comment 2

[Daniel Holbert [:dholbert]]

I can reproduce.

The web console shows this error spammed over and over for me, as the terminal shows the spinning throbber-graphic forever:

XHR GET https://t954tjyx1.us-west-1.run.claw.cloud/
CORS Missing Allow Origin

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://t954tjyx1.us-west-1.run.claw.cloud/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 403.

I see this in the network devtools panel, too -- repeated GET requests for https://t954tjyx1.us-west-1.run.claw.cloud/ which fail with status 403 Forbidden and the Transferred column showing "CORS Missing Allow Origin"

The fetch happens here in https://terminal.us-west-1.run.claw.cloud/_next/static/chunks/pages/index-888c843aa1dfe5a8.js :

void 0 === i ? void 0 : i.data;
                  fetch(n, {
                    mode: 'cors'
                  }).then(e => {
                    200 === e.status &&
                    (l(!1), s(n))
                  }).catch(e => {
                  })

(where n is https://t954tjyx1.us-west-1.run.claw.cloud/)

If I find the request in the Network devtools panel and do copy-as-curl, then I can confirm that indeed the response is missing the Access-Control-Allow-Origin header for the curl command for Firefox's request, vs. the response has https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-UA`Access-Control-Allow-Origin` for the curl command for Chrome's request.

Comparing the two curl commands, this is the header that seems to be necessary in order for the server to send us Access-Control-Allow-Origin:

  -H 'sec-ch-ua: "Not;A=Brand";v="99", "Google Chrome";v="139", "Chromium";v="139"' \

The value of that header doesn't matter; but as long as I send any string for it (even an empty string like -H 'sec-ch-ua: ""'), then the response includes access-control-allow-origin: https://terminal.us-west-1.run.claw.cloud. Otherwise the response is missing the access-control-allow-origin header entirely.

It looks like this is an experimental header defined at https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-UA and Firefox is the only browser that doesn't send it. I couldn't immediately find a bug on sending it, so I'll file one and mark that as a platform-bug here.

Comment 3

[Daniel Holbert [:dholbert]]

Filed bug 1973894 as a platform bug here.

Relatedly, this site seems to be hosted on cloudflare... I wonder if this is a cloudflare bug or something we should be reaching out to them about? (Not sure whether it's some cloudflare infrastructure that's inadvertently depending on sec-ch-ua here, or the "claw" service, or something else.)

Randell, you might be interested to take a look here (or pass along to someone else on the networking team); do you know if this is something we could/should reach out to cloudflare about? Not sure how weird it is that they seem to be depending on this header here.

Comment 4

[Daniel Holbert [:dholbert]]

[er, meant to ni jesup; see previous comment]

Comment 5

[Daniel Holbert [:dholbert]]

(Note, the "t954tjyx1" prefix in my URLs above seems to be a one-time domain that's valid for a limited period of time (maybe minutes). So when I'm e.g. poking at curl commands extracted from Firefox and Chrome to add/remove headers like this sec-ch-ua header, I'm only able to poke like that for a limited period of time before the URL stops working entirely. When that happens, though, I can just get a new URL from reloading the browser tab -- and possibly clicking through a Cloudflare "verify you're human" page -- and then repeat the STR here to get new network requests in the devtools network panel that I can copypaste into a new curl scratchpad.)

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #2)

Comparing the two curl commands, this is the header that seems to be necessary in order for the server to send us Access-Control-Allow-Origin:

  -H 'sec-ch-ua: "Not;A=Brand";v="99", "Google Chrome";v="139", "Chromium";v="139"' \

The value of that header doesn't matter; but as long as I send any string for it (even an empty string like -H 'sec-ch-ua: ""'), then the response includes access-control-allow-origin: https://terminal.us-west-1.run.claw.cloud. Otherwise the response is missing the access-control-allow-origin header entirely.

Given this^ and the support table at https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-UA , I assume this is broken in Safari/WebKit as well. I don't have that handy to test at the moment, though (currently on Linux), but I can test tomorrow.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

Given [the] support table at https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-CH-UA , I assume this is broken in Safari/WebKit as well. I don't have that handy to test at the moment, though (currently on Linux), but I can test tomorrow.

Confirmed -- Safari hits the exact same issue that we hit here (terminal stuck with a throbber GIF, with DevTools console spamming errors about a resource failing to load due to Access-Control-Allow-Origin, similar to those at the top of comment 2).

That might be relevant to mention if/when we do outreach here.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Valentin, any ideas?

Comment 9

[Valentin Gosu [:valentin]]

Seems like we depend on bug 1973894 adding the sec-ch-ua header request header.
In the mean time, I think we could ship a webcompat intervention that sets the header for this one site/request?