You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When an Image block contains an image and the image upload fails for whatever reason, the host app typically keeps track of that somehow to allow the user to retry an upload and to let Gutenberg know which Image Blocks have a failed image within (so the editor knows and is able to correspondingly show the upload error UI to the user). Currently, tapping on the block's trash icon (to remove a failed image) is not informed to the host app, so the app can't update its state to know which images should be retried. This leads to UX communication artifacts, for example the host app's upload error and progress notifications being inconsistent with what can be seen in the editor.
To Reproduce
Steps to reproduce the behavior:
use WPAndroid (preferably on a clean installation to avoid potentially confusing other media failed issues):
Create a new draft on the Block editor
turn airplane mode ON
add an image block and assign an image to it
add another image block and assign another image to it
now remove once of the blocks by tapping on the block's trash icon
tap on the image on the other block, to get the "retry/remove/retry all" dialog
tap on "retry all"
Observe the error notification will still say "2 files not uploaded", when in reality we only wanted to upload 1 image, not 2 (as we removed one of the blocks).
Expected behavior
When removing an Image Block that contains a failed to upload image, then retrying other failed uploads, count in the notifications should be consistent.
Smartphone (please complete the following information):
on the Gutenberg side, the detection of an image block being removed is already made here. We should also let the callback know not only when an in progress upload is happening (i.e. remove the check for this.state.isUploadInProgress), but also for any other case (and let the host app decide what to do there).
on the host app side and specifically the WPAndroid app should remove the mediaId from mFailedMediaIds array in GutenbergEditorFragment, and also call the fragment listener's onMediaDeleted when the user taps on the trash icon on an ImageBlock (pretty much follow the retry Dialog's REMOVEaction onClick body ). Otherwise, artifacts in upload progress notification count and upload error notifications may happen, as these rely on what that array contains.
The text was updated successfully, but these errors were encountered:
Describe the bug
When an Image block contains an image and the image upload fails for whatever reason, the host app typically keeps track of that somehow to allow the user to retry an upload and to let Gutenberg know which Image Blocks have a failed image within (so the editor knows and is able to correspondingly show the upload error UI to the user). Currently, tapping on the block's trash icon (to remove a failed image) is not informed to the host app, so the app can't update its state to know which images should be retried. This leads to UX communication artifacts, for example the host app's upload error and progress notifications being inconsistent with what can be seen in the editor.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
When removing an Image Block that contains a failed to upload image, then retrying other failed uploads, count in the notifications should be consistent.
Smartphone (please complete the following information):
Additional context
First spotted while testing this wordpress-mobile/WordPress-Android#10791 (comment) , and related to the work done in #715,
and https://github.com/WordPress/gutenberg/pull/14391/files#diff-a61b3f346c11f42236eb2b1a783bf9bfR93.
Potential solution:
this.state.isUploadInProgress
), but also for any other case (and let the host app decide what to do there).mFailedMediaIds
array inGutenbergEditorFragment
, and also call the fragment listener'sonMediaDeleted
when the user taps on the trash icon on an ImageBlock (pretty much follow the retry Dialog'sREMOVE
action onClick body ). Otherwise, artifacts in upload progress notification count and upload error notifications may happen, as these rely on what that array contains.The text was updated successfully, but these errors were encountered: