Re-opening post with in-progress uploads does not display loading indicator [iOS only]

[dcalhoun]

Description

If a post is closed and re-opened while a media upload is in-progress, the editor UI does not display dimmed media or a loading indicator. This issue only occurs on iOS, Android functions as expected.

Step-by-step reproduction instructions

1. Create a new post in the mobile app.
2. Save a draft.
3. Add a Gallery/Media & Text/Image/Video block.
4. Upload media for the block.
5. While the media is still uploading, close the post and update the draft.
6. Re-open the post while the media is continuing to upload.

Expected behaviour

Each in-progress upload is dimmed and displays a loading bar.

Actual behaviour

Each in-progress media is not dimmed and no loading bar is displayed.

Screenshots or screen recording (optional)

https://user-images.githubusercontent.com/438664/223559146-4cc43478-1838-4f7f-8743-174691b0dc56.mp4

WordPress information

• WordPress version: 6.2
• Gutenberg version: 15.2.4
• Are all plugins except Gutenberg deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? Yes

Device information

• Device: iPhone SE
• Operating system: iOS 16.4
• WordPress app version: 21.9 and back to at least 21.4

[fluiddot]

Thanks for reporting this issue @dcalhoun 🙇.

I managed to reproduce the issue and I'd like to share, as an additional note, that the HTML generated after re-opening the post contains local URLs to media items. Here is an example of adding a Gallery block:

<!-- wp:gallery {"linkTo":"none"} -->
<figure class="wp-block-gallery has-nested-images columns-default is-cropped">

⬇️ =========== This image WAS uploaded ✅ =========== ⬇️
<!-- wp:image {"id":4735} -->
<figure class="wp-block-image"><img src="https://<SITE>.files.wordpress.com/2023/03/941-5000x5000-1-1.jpg?w=1024" alt="" class="wp-image-4735"/></figure>
<!-- /wp:image -->

⬇️ =========== This image WASN'T uploaded ❌ =========== ⬇️
<!-- wp:image {"id":1407072289} -->
<figure class="wp-block-image"><img src="file:///<LOCAL_DIR>/Library/Developer/CoreSimulator/Devices/1F87E142-943E-478B-A4F4-47BE36D845E8/data/Containers/Data/Application/37554176-D0EA-4B24-BE2B-B8012633709B/Library/Caches/Media/thumbnail-p467-2532x2532.jpeg" alt="" class="wp-image-1407072289"/></figure>
<!-- /wp:image -->

⬇️ =========== This image WAS uploaded ✅ =========== ⬇️
<!-- wp:image {"id":4733} -->
<figure class="wp-block-image"><img src="https://<SITE>.files.wordpress.com/2023/03/img_0005-1.jpg?w=1024" alt="" class="wp-image-4733"/></figure>
<!-- /wp:image -->

⬇️ =========== This image WAS uploaded ✅ =========== ⬇️
<!-- wp:image {"id":4734} -->
<figure class="wp-block-image"><img src="https://<SITE>.files.wordpress.com/2023/03/img_0004-1.jpg?w=683" alt="" class="wp-image-4734"/></figure>
<!-- /wp:image -->

⬇️ =========== This image WASN'T uploaded ❌ =========== ⬇️
<!-- wp:image {"id":-203540197} -->
<figure class="wp-block-image"><img src="file:///<LOCAL_DIR>/Library/Developer/CoreSimulator/Devices/1F87E142-943E-478B-A4F4-47BE36D845E8/data/Containers/Data/Application/37554176-D0EA-4B24-BE2B-B8012633709B/Library/Caches/Media/thumbnail-p470-2532x2532.jpeg" alt="" class="wp-image--203540197"/></figure>
<!-- /wp:image -->

⬇️ =========== This image WASN'T uploaded ❌ =========== ⬇️
<!-- wp:image {"id":64895260} -->
<figure class="wp-block-image"><img src="file:///<LOCAL_DIR>/Library/Developer/CoreSimulator/Devices/1F87E142-943E-478B-A4F4-47BE36D845E8/data/Containers/Data/Application/37554176-D0EA-4B24-BE2B-B8012633709B/Library/Caches/Media/thumbnail-p471-2532x2532.jpeg" alt="" class="wp-image-64895260"/></figure>
<!-- /wp:image -->

⬇️ =========== This image WASN'T uploaded ❌ =========== ⬇️
<!-- wp:image {"id":333330717} -->
<figure class="wp-block-image"><img src="file:///<LOCAL_DIR>/Library/Developer/CoreSimulator/Devices/1F87E142-943E-478B-A4F4-47BE36D845E8/data/Containers/Data/Application/37554176-D0EA-4B24-BE2B-B8012633709B/Library/Caches/Media/thumbnail-p472-2532x2532.jpeg" alt="" class="wp-image-333330717"/></figure>
<!-- /wp:image --></figure>
<!-- /wp:gallery -->

The above case makes the post be modified and when it's saved the following happens:

1. The images pointing to local URLs are not shown and a placeholder is rendered instead.
2. In a matter of a couple of seconds, the local URLs are changed to remote URLs, and images are rendered again.
3. The post is marked again as modified. Saving the post a last time preserves the remote URLs.

Although the content seems that is not lost, the experience is far from good, especially as it requires saving the post two more times.

[dcalhoun]

@fluiddot the post HTML content you share isn't too surprising to me given upload, in theory, are still in-progress. I presume the local file paths represent the files that are currently still uploading. The surprising aspect is the lack of loading indicators for those files.

The above case makes the post be modified and when it's saved the following happens:

1. The images pointing to local URLs are not shown and a placeholder is rendered instead.

That is interesting the experience differs between an explicit save and merely re-opening the post. The latter, as showcased by the video in the issue description, appears to display the local image itself.

2. In a matter of a couple of seconds, the local URLs are changed to remote URLs, and images are rendered again.

I imagine this is the result of the upload finishing and the swapping of the URLs you mention.

3. The post is marked again as modified. Saving the post a last time preserves the remote URLs.

I suppose the modified post is expected given the URLs change.

[fluiddot]

I investigated this issue a bit further and comparing the logic between iOS and Android, I think I found what's probably the culprit:

Media blocks call the function mediaUploadSync upon block mount (Image block, Video block). The main goal of this function is to check the media items associated to the post and depending on their status, call back the editor with that information.

On Android:

• mediaUploadSync bridge function
• mediaUploadSync glue code => call to onQueryCurrentProgressForSavingMedia
• onQueryCurrentProgressForSavingMedia logic in WP-Android

As you can see, mediaUploadSync checks for potential failed uploads and updates uploads that are in progress. This explains why this issue doesn't happen on Android, as when updating the state of uploads in progress will make the progress bar to be display.

However, this behavior is not applied on iOS:

• mediaUploadSync bridge function
• Handler for mediaUploadSync => call to syncUploads in WP-iOS
• syncUploads logic

In this case, potentially failed uploads are checked but not uploads in progress.

---

A potential workaround to address the issue would be to replicate the Android's logic on iOS and call back the editor with the uploads in progress when syncing media uploads.