This commit is contained in:
Joey Hess 2024-12-03 16:33:03 -04:00
parent 501b5b09f6
commit 79a160b760
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 60 additions and 0 deletions

View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2024-12-03T18:41:08Z"
content="""
Tried in chromium, also seeing it block sometimes, though not always, on
page loads.
This seems rather similar to this old bug involving the same software:
<https://github.com/yesodweb/wai/issues/146>
But not I think quite the same, because that was caused by
a long delay between clicks, and this happens when clicking immediately.
The browser's network console shows a few ms for all resources to load,
except the page itself which for some reason takes a log time.
tcpdump shows that chromium does not send a request for that page until
many seconds after the click. The response to the request is immediate.
Before that point there is only some SYN/ACK traffic. Which looked a bit
weird maybe.
"""]]

View file

@ -0,0 +1,38 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2024-12-03T20:13:35Z"
content="""
Looking at the network inspector, it seems more likely a given click stalls
when there are multiple long polling requests ongoing at the same time
(which show as "pending").
So on a hunch, I disabled javascript in chromium. No more hangs.
I suppose maybe chromium has a small pool of connections to the web server,
and if all of those get blocked up doing long polling, and if it doesn't
cancel those when navigating away from the page that made the long polling
request, it could block?
But why wouldn't it cancel them? The requests were made by the page it's
navigating away from. Maybe it cancels them only once it's loaded the new
page.
I do think that's it though. When I open 2 tabs both to the webapp,
a request in one tab can be stalled, and pressing escape in the other tab,
when it cancels the long polling requests, will unstall it.
Amazingly, chromium is limited to 6 concurrent connections per server, with
no way to configure it! And the front page of the webapp opens several
long polling connections.
In firefox, by comparison, the network inspector shows the long polling
connections apparently disappear when navigating to a new page. But, there
is a similar problem, when opening 2 tabs to the webapp, one can stall,
due to the long polling connections open by the other tab.
So, I think the solution to this will either need to involve some change
to the long polling javascript, if there is some way to make chromium
cancel the request when navigating away... Or it would need to replace the
long polling with something else entirely.
"""]]