TYPO3 Core

I wasn't able yet to come up with a solution.

At least the notification should have a duration. This improves the UX as the editor doesn't have to close many of those messages.

Is there a possibility to safely cancel all pending request when a modal is closed? Otherwise the browser cancels the request and we get different errors per browser. See: https://github.com/shuding/request-cancellation-test

Most browsers will cancel ongoing or queued fetch tasks, when unloading the document (spec). It usually happens when navigating away from the current page, which causes a fetch error if there is an unfinished request.

However, browsers are behaving differently and throwing different errors (listed below). It can be really annoying to differentiate them from normal errors if you are using Sentry, or showing a “failed to fetch” hint in the UI.

The error occurs during the loading process of the page tree/filelist if the data picker is closed when selecting a reference before the page tree/file list has been completely loaded. This process is built entirely on the frontend and calls a data fetch URL once for the data of the page tree/file list, which returns the nodes of the page tree/file list in JSON format.

I started my analysis in the TYPO3 code repository, where I came across the file https://github.com/TYPO3/typo3/blob/11.5/typo3/sysext/core/Resources/Private/Language/locallang_misc.xlf via the error message "Navigation loading error". Here, the T3 translation for the errors is defined in lines 360-365; I was directed to the file https://github.com/TYPO3/typo3/blob/11.5/Build/Sources/TypeScript/backend/Resources/Public/TypeScript/SvgTree.ts via the translation ID "tree_networkError". Here, the error code is defined locally for the file in lines 132 and 133. A look at lines 201-219 in this file shows how the page tree is loaded. In the case of an error, the error message from the HTTP response is passed to a local function. If you look at lines 633-649 in the same file, you can see that the content of the passed error is transferred to the notification element from the TYPO3 backend - here it is still important, since the error does not come from the server, it becomes clear in lines 640-643 that the T3 standard texts are used here.

In order to understand exactly why the error happens, I took another look in the backend. If you open the file picker and close it before the page tree/file list is loaded (URL: https://www.****.***/typo3/ajax/filestorage/tree/fetchData?token=73d8e6bb423a0642de98fbc71c32500b43d056f6 - token may differ per user and session) you can see in the network tab of the inspector that the request was cancelled. As described above, no error code is evaluated by the HTTP response, but only the cancellation as such is output as an error. If the data fetch URL is called up directly in the browser, the backend needs 2.2s until a response is generated. It would be better to check why the backend takes so long.

As described above, no error code is evaluated by the HTTP response, but only the cancellation as such is output as an error. If the data fetch URL is called up directly in the browser, the backend needs 2.2s until a response is generated. It would be better to check why the backend takes so long.

That's also a good second point, but the response time is very dependend on the machine and the fileadmin size.

IMHO the main problem is, that an actively canceled request by closing the modal (escape or image selected) shouldn't throw any error. As a user I don't care about a still loading svg tree (or any other request working in the background) when I close the modal/module/...
But I want to have real errors shown to me, when e.g. the svg tree can't be loaded.

I fully agree. Cancellation of loading the svg tree should not throw an error.

Showing an error message to the editor should always lead to adaption to his behavior.
This error message is heavily misleading: it does not describe the actual error, nor does it show improvement.

For this reason the error must not be shown to the editor at all. But shall be logged for debugging purpose.

Even if the navigation tree was not properly loading, the error should not appear to the editor because there is simply no error message leading to a better behavior. However, the error should be logged in the error logs.