Automattic/stories-android

Story editing: sometimes can't open original background image

Closed this issue · 2 comments

mzorz commented

During testing of #663, it happened to me several times that creating a Story then trying to edit it would offer the "Limited Story Editing" dialog, which only happens when a Story frame could not be found in Prefs or when the original background image used cannot be accessed at the time it was attempted to be loaded.
The code that pre-checks this is in the areAllStorySlidesEditable() method in the various forms of isValidSlide() which can be found here.

For example:

   fun isValidSlide(siteId: Long, localId: LocalId): Boolean {
        return checkSlideIdExists(siteId, localId) &&
                checkSlideOriginalBackgroundMediaExists(siteId, localId)
    }

The problem here is it says it couldn't be loaded so it assumes this was not created on this handset (which is not true).

Also oftentimes, just trying again once more will work, so I wonder if this is a timing issue that the ContentResolver doesn't have the URL available at that moment.

mzorz commented

I've been able to reproduce this one only a couple of times after the latest changes (I'd say 2 times out of 30 or 40 tries), with the following steps:

  1. open existing story block with at least 2 slides
  2. reorder the first one (move it to the right)
  3. tap the check mark on the story composer
  4. while the story is updating in Gutenberg, tap BACK. You may get the toast that prompts to wait until save is done, tap again until you can get away with it. (*)
  5. now try open, observe the Limited Story Editing dialog appears

Going back and then opening the same block once more will give no trouble this second time.

(*) most of the times I did this frantically, I'd get the following crash on debug builds (see reasoning for this debug crash here):

2021-04-27 11:52:30.521 30979-30979/org.wordpress.android E/AndroidRuntime: FATAL EXCEPTION: main
    Process: org.wordpress.android, PID: 30979
    java.lang.RuntimeException: Debug build crash: Post had changes that needed to be saved when exiting the editor, but there was an autosave pending. This can occur when the user makes changes just before exiting the editor and the autosave debouncer does not have time to fire. This only crashes on debug builds.
        at org.wordpress.android.ui.posts.EditPostActivity.lambda$updateAndSavePostAsyncOnEditorExit$36$EditPostActivity(EditPostActivity.java:1740)
        at org.wordpress.android.ui.posts.-$$Lambda$EditPostActivity$vJjst50aiDHnVjIfebXhKtN150Y.onPostUpdatedFromUI(Unknown Source:6)
        at org.wordpress.android.ui.posts.EditPostActivity.lambda$updateAndSavePostAsync$35(EditPostActivity.java:1705)
        at org.wordpress.android.ui.posts.-$$Lambda$EditPostActivity$iPAmveF4zvMghUZtc2nvk10nj_8.invoke(Unknown Source:6)
        at org.wordpress.android.ui.posts.EditPostRepository$updateAsync$1.invokeSuspend(EditPostRepository.kt:128)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:56)
        at android.os.Handler.handleCallback(Handler.java:938)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:223)
        at android.app.ActivityThread.main(ActivityThread.java:7660)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
2021-04-27 11:52:30.523 1798-32241/? I/DropBoxManagerService: add tag=data_app_crash isTagEnabled=true flags=0x2
2021-04-27 11:52:30.523 1798-6493/? W/ActivityTaskManager:   Force finishing activity org.wordpress.android/.ui.posts.EditPostActivity

At one point when I also was able to reproduce (and only once), I got this other line in the logcat:

2021-04-27 14:26:42.682 742-16693/org.wordpress.android E/WordPress-EDITOR: Impossible to save the post, we weren't able to update it.

Not sure if this is related though.

So basically, this is I think something related to:

  • a slow update followed by a quick read (something may not end up having been entirely saved before the next read)
  • either the background image not being available next time, but available again after a while (IMO less likely / far fetched)
  • the SharedPrefs not having the slide serialized before we query again if the slide exists (not sure exactly how this would happen though)

Given how difficult it is to reproduce, and given there's no actual loss of data (it will work next time you edit the block), while the Dialog may be a bit misleading, I'm inclined to think we can close this one and open if / when we hear reports about it.
Another option would be to edit the Limited Story Editing Dialog:

Current: (see here)

This story was edited on a different device and the ability to edit certain objects may be limited.

Proposed change:

This story may have been edited on a different device and the ability to edit certain objects may be limited.

Interested in hearing your thoughts @aforcier 🙏

aforcier commented

I think given this analysis we can probably just leave this as-is, close this issue, and reopen if we hear any reports. 👍 🤝

  • 👍1