Get "Navigation loading error. Got unexpected response from the server. Please check logs for details." when fetch request is canceled. - Part 2
"Reopen" of https://forge.typo3.org/issues/97003
TYPO3 shows an error message about unexpected response from server in case browser cancel fetch request in the Backend.
A coworker notified me about this issue in a project when using the fileadmin with many images. The customer is very annoyed by those flash messages when they edit their content.
By the way: the same error Message is triggered for the page tree and the file tree as they both use the SvgTree class.
The problem is, that the editors select the image in the modal faster than the tree is built. When the image is selected the request is canceled, and the JS triggers the flash message. Error still exists in TYPO3 11.5.26-dev and 12.3.0-dev.
This can be easily tested with a plain TYPO3 11/12 and one image by slowing down the response of the controller with
sleep(10) here: https://github.com/TYPO3/typo3/blob/11.5/typo3/sysext/backend/Classes/Controller/FileStorage/TreeController.php#L57
Updated by André Buchmann 9 months ago
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.
Updated by Volker Braun 9 months ago
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.
Updated by André Buchmann 9 months ago
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.
Updated by Floyd Hermes 9 months ago
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.