TYPO3 Core

in cms-backend the CustomElements (like typo3-formengine-container-files ) might be registered and initialized before the actual markup is loaded, leading to unresponsive interface elements or events/actions not happening.

I was able to reproduce the problem on my Mac by installing the "Network Link Conditioner" preference pane from the XCode Additional Developer tools, and setting my connection to 'Very bad network'

The effect of the problem manifested for me when in cms-backend/Resources/Public/JavaScript/form-engine/container/files-control-container.js the following line is called:

window.customElements.define("typo3-formengine-container-files",FilesControlContainer)

while the concrete form is still loading and the

<typo3-formengine-container-files></typo3-formengine-container-files>

is not in the dom yet. This means this line is called while document.readyState is still loading or the DomReady event is not yet called.

A window.setTimeout mitigated the problem for me for now, but this should rather be part of the initialzation which happens in the DocumentService.ready() promise. Maybe some kind of initialization queue for these kind of CustomElements?

This is not an academic problem, this is a real world problem brought to me by editors which happen to have complicated setups or ancient connections...

The effect on typo3-formengine-container-files is - when it is initialized too early - that you can not open the files, not deleted or hide them. Additionally the insert event is not registered, which means you can open the picker, choose a file, and nothing happens, not even an error..

I had as well reports for this happening to the Datepicker as well, which I guess is registered in a similar way.

This is valid for TYPO3 12 and 13.