Show file upload progress and placeholder media message in chat.

[anakin78z]

Implements #2375

I'm aware of the work in progress at #5317 but I couldn't get it to work when I tried it, and since there were a lot of changes with the ChatKit removal, I thought it best to start fresh.

🖼️ Screen captures:

The X button in the top right cancels the upload.
Uploading images are blurred to indicate they are not yet fully sent (they remain blurred until the device receives the chat message from the server). The idea is to make it obvious that the messages can't be interacted with as a regular media message.

Video demo:

https://youtube.com/shorts/FMw_yvhxXL4

🚧 ISSUES

I created issue #6081 for the following. It will be fixed once #6124 is merged:

After a file has uploaded, but before the insurance request is made, tapping the image/video fails. While investigating this, I noticed that the return values from the WebSocket and the insurance request are different:

The link and path parameters both have different values. I'm not sure if this is a server issue, or if the responses need to be handled differently, but it's odd that the link would be different.

My server version is 33.0.0

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed
• 🔖 Capability is checked or not needed
• 🔙 Backport requests are created or not needed: /backport to stable-xx.x
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

[mahibi]

Glad to see works that build on to of the recent changes (yes it makes sense to start with a fresh approach instead the old approach for chatkit).

Please let us know if there are any questions or it is ready to review.

[sowjanyakch]

Hey @anakin78z , thank you for the PR. I will take a look at this PR soon.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[sowjanyakch]

Hello @anakin78z - could you rebase on the latest master and resolve merge conflicts?

To resolve linter issues, please run ./gradlew ktlintFormat.

[anakin78z]

@sowjanyakch merge conflict fixed & linter issues resolved.

[sowjanyakch]

I tested this PR with different scenarios and noticed an issue.

Start uploading a video file and then disconnect the device from Wi-Fi. As expected, the upload fails and a “Failure” warning is shown. However, after reconnecting to Wi-Fi, a progress bar appears again, which gives the impression that the upload is being retried.

But the upload is not retried, and after sometime "{file}" message is posted in the chat. To make this behavior clearer, we could either retry the upload when the network is restored, or avoid showing the placeholder message and instead display a clear failure state in the case of failed file upload — for example, a snackbar indicating that the file upload has failed.

Btw, for NC34 - the file upload implementation changes and use new API's for the same #6127 and it is currently under review.

[anakin78z]

@sowjanyakch While testing the issue with resuming uploads, I ran into an issue here, where it couldn't copy the file to cache because there wasn't enough disk space.

java.io.IOException: write failed: ENOSPC (No space left on device)

I don't really understand why we're copying the file after the upload is complete? If you could shed some light on that, I would appreciate it.

If the copy is necessary, we'll have to add a check here or in FileUtils to handle the exception.

[anakin78z]

But the upload is not retried, and after sometime "{file}" message is posted in the chat.

@sowjanyakch The {file} message is actually coming from the server:

Receiving : okhttp3.internal.ws.RealWebSocket@1de6f4e {"type":"event","event":{"target":"room","type":"message","message":{"roomid":"7tbeykxa","data":{"type":"chat","chat":{"comment":{"id":3649,"token":"7tbeykxa","actorType":"users","actorId":"devjens","actorDisplayName":"Dev Jens","timestamp":1777486849,"message":"{file}","messageParameters":[],"systemMessage":"","messageType":"comment","isReplyable":true,"referenceId":"a51e6407006543ea94bd7754f2844fd3","reactions":{},"expirationTimestamp":0,"markdown":true,"threadId":3649}}}}}}

It looks like the server stores the message even if the file upload fails. We could catch this by looking for {file} messages with no file attachments, but we'd then have to show some kind of error message.

I'm not sure if this changes with the new API? Can you link me to the documentation, please?