[Webkit-unassigned] [Bug 257965] REGRESSION (iOS 16.4): Safari occasionally locks up and stops completing XHR requests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=257965

Joel <fligosmate at hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fligosmate at hotmail.com

--- Comment #6 from Joel <fligosmate at hotmail.com> ---
We have users experiencing very similar issues:

> At some point in the session, a API request would appear to hang, eventually timing out (the application times out the request, this timeout is not from iOS or Safari itself). From that point on, all XHR requests fail to resolve and are eventually timed out as well. After this happens, the tab seems to be "fouled" and all requests fail.

Same behavior observed by us, with the difference that the floodgates are released at an arbitrary point in time in the future, sometimes even within the 60 seconds, making no timeouts occur.

> We are confident network conditions are fine in a majority of these cases are these are not "true" timeouts.

Same here, fetch requests are both starting and completing just fine during this "freeze".

> The first call to hang/timeout is not always the same call, or even in the same user flow in the application. We also haven't seen this behavior on any other browser. Given this, we're confident the issue isn't with the application itself and is most likely a Safari bug.

Same observed by us.

Furthermore, we have client logs from the network tab, along with server logs, which together paint the story that Nick shared with you of XHR requests locking up. Summarized, they say:
1. Several XHR requests* are started, and stay in a pending state for very long.
2. Some fetch requests are performed in parallell, and they start and complete within reasonable time frames.
3. If 60 seconds pass, the XHR requests time out**. If not, a successful response is returned.
4. In case of a successful response, server logs indicate that no XHR request reached the server until very shortly before the response was sent.
5. Meanwhile, XHR requests from other clients (Windows Edge in this example) are handled just fine during the same time frame that the requests are held up, indicating no server issues.

*XHR requests towards one domain only, it actually works fine for requests targeting another domain, in the same timeframe. Perhaps this lends some credit to Nick's cookie theories?

**In one case, the OPTIONS request was recorded on the server, but then the request timed out without performing the follow-up request, indicating the floodgates were released just before 60 seconds passed. Most of the time, there is no such trace, indicating that the timeout occurred before anything reached the server.

We have the option to migrate from XHR to fetch, so we are probably going to set up slow request tracking, then migrate to fetch, and then see if there is any measurable difference.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240315/5c434e73/attachment.htm>