@bastianallgeier Still doesn't work :(

That's very weird. Works perfectly for me now. Ok, then I need to double-check again.

It does work for me. @afbora sure there aren't any old files cached, e.g. in media/panel if you're running it via npm run build not npm run dev?

@distantnative I'm testing always via build. The issue still valid for me. Sometimes works sometime not. With this PR better but it's not completely fixed.

@afbora Very weird. Any insights on the preconditions to have it succeed vs. when it fails?

@distantnative I can reproduce it with every request via browser's slow 4G or 3G network throttling feature.

Not sure but I think this content lost happens when pages/field/files request done after save request.

@afbora You mention "save request" - so it's not just uploading what you are trying to do (as described in the original issue) but some combination with uploading and directly saving (and if you say slow connection, maybe you are trying to super quickly save before the upload request is actually done)?

But then I would think this fix might still be right, but we have in addition still problems with a race condition between content.save and content.publish (or similar).

I mean /save request after uploading done (automaticly and after modal closed) with "save request" not page save request via manual clicking.

Mmm ok. Couldn't reproduce it. Even when throttling speed.

One thought could be if insertFile takes longer than the update call. There is a setTimeout involved. So maybe that.

@distantnative Here the screencast:

I think our main issue really is the view reloading in the done event of the uploader. I have an idea.

@distantnative @afbora I've refactored the code quite a bit and I hope this PR is not getting too big.

• We had a couple places in the TextareaInput component that made race conditions possible. I've refactored them with async/await to be more in control of what we actually do
• The upload module had a few weird inconsistencies with event emitting. I've cleaned it up to better see what we are doing at which point
• We only need to emit the model.update event once all file uploads are finished. This will trigger all sections to be reloaded. A full panel.view.reload() is not necessary here and will always lead to issues with open drawers.

Sandbox

I've added a new "Others > Uploads" examples page where we can test textarea, structure, blocks and files fields with uploads and we can also see if a files section updates accordingly.

@bastianallgeier I've tested now. There is restore selection issue at first glance.

Click/select to random place of the paragraph text and try to drag/drop items to selected area. You can repeat this with selecting random places of the text with drag/drop an item. You'll see the issue that dragtexts are inserted always same places instead of selected area.

Your tests and comments made me realize that I had a logical issue in the way the selectionRange was stored but not updated when dialogs are opened. This makes no sense and leads to the issues that you describe. Then I realized that we can use the onselectionchange event of the input perfectly to always store the latest selection range and restore that one if it exists. This works really well and cleans up the code some more.

I've tested everything in Firefox, Chrome and Safari and it seems to run smoothly now, but I would want to wait for another round of tests from your side.

@bastianallgeier I tried hundreds of times in different ways, but on one of my first attempts, the file disappeared once. Then I couldn't reproduce the problem again. I think it was cache related. So everything seems to be working fine 🎉

@afbora that's great. I think we should wait for another look from @distantnative before we give it a go. I guess it's ok if we put it into rc.4

Haven't had much chance to test it myself, but no further comments on the code and totally fine for me to have it merged if you two tested it successfully 👍