IllegalViewOperationException: Unable to execute operation dispatchViewManagerCommand on view with tag: 159, since the view does...

[sentry-io]

Sentry Issue: WORDPRESS-ANDROID-1TS

IllegalViewOperationException: Unable to execute operation dispatchViewManagerCommand on view with tag: 159, since the view does not exists
    at com.facebook.react.uimanager.UIImplementation.assertViewExists(UIImplementation.java:867)
    at com.facebook.react.uimanager.UIImplementation.dispatchViewManagerCommand(UIImplementation.java:747)
    at com.facebook.react.uimanager.UIManagerModule.dispatchCommand(UIManagerModule.java:660)
    at com.facebook.react.uimanager.UIManagerModule.dispatchViewManagerCommand(UIManagerModule.java:655)
    at java.lang.reflect.Method.invoke(Method.java)
...
(9 additional frame(s) were not displayed)

Unable to execute operation dispatchViewManagerCommand on view with tag: 159, since the view does not exists

[JavonDavis]

@daniloercoli do you think this is related to #8838 ?

[designsimply]

90-day impact: ~23 per day
Users affected in the last 90 days: 1600
^{https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/}

[daniloercoli]

Yes, it sounds pretty similar to me. Hope we will get the ability to include testing steps, otherwise could be a bit hard to reproduce the problem.

(Note: we should try to repro the problem by rotating the device while a modal view is on the screen. it may trigger this error on Android)

[designsimply]

90-day impact: ~32 per day
Users affected in the last 90 days: 2200
^{https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/}

[designsimply]

90-day impact: ~41 per day
Users affected in the last 90 days: 2500
^{https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/}

[malinajirka]

I was able to reproduce this bug on both emulator and my hw device.

1. Create a new post
2. Add an image block
3. Click on the "bin" on the image block
4. Boom

Emulator API 28
Pixel 3 API 29

[maxme]

Looks similar to #8838

[malinajirka]

Full error stack trace in case it'd be useful
https://justpaste.it/57ypn

[daniloercoli]

I can reproduce the problem on other blocks too. I think the culprit is on the first "empty" block we show on empty editor.
Sometime the problem doesn't happen on the 1st removal of the block, but the 2nd time.

Steps to repro - Case A

• Create a new post
• Add an Page break block
• Click on the "bin" on the Page break block
• Boom

Steps to repro - Case B

• Create a new post
• Add an Page break block
• Click on the "bin" on the Page break block
• This time the block is removed without a crash
• Add an Page break block
• Click on the "bin" on the Page break block
• Boom

[designsimply]

Ditto. I was able to see the editor stop after removing any "empty" block once or twice and when that happens in the app I see the "WordPress keep stopping" error pop up:

^{Tested with WPAndroid 13.6-rc-3 on Pixel 3 Android 10.}

[marecar3]

Hey @designsimply it seems that it's very similar to: wordpress-mobile/gutenberg-mobile#1549

[designsimply]

Yes! It does! I'll close wordpress-mobile/gutenberg-mobile#1549 in favor of this issue. Thank you @marecar3!

[mkevins]

I just encountered this while testing the gutenberg-mobile release/1.17 branch via WordPress-Android develop, and also reproduced on the demo app, and on gutenberg-mobile develop.

I think @daniloercoli is correct:

I think the culprit is on the first "empty" block we show on empty editor.

It may have something to do with when an empty paragraph block is replaced by the new block from the appender. There's a subtle pattern about which blocks can "trigger" the bug:

Steps:

1. Add empty paragraph block
2. Add SOME_NEW_BLOCK
3. Tap trash can on SOME_NEW_BLOCK

Results:

SOME_NEW_BLOCK	Result	Result after tapping inner EditText
Paragraph	✔️
Heading	✔️
Image	💥	✔️
Video	💥	✔️
List	✔️
Quote	✔️
Code	✔️
More	💥
Page Break	💥
Separator	💥
Media & Text	💥	✔️
Group	💥
Spacer	💥

The pattern seems to be that the crash does not occur for blocks that have an EditText, and does occur for blocks that don't have an EditText. The exception is Media & Text. Interestingly, tapping trash icon on Media & Text crashes, but if you first tap the inner text within the Media & Text block (so the caret appears), then tap outside, the block can be deleted without a crash. Also, if I tap the caption (so the caret appears) on either an Image or Video block, the crash does not occur.

[hypest]

Awesome table @mkevins, thanks for being elaborate there!

FWIW, I tried some of those cases and confirmed your results. Also, I've confirmed that @marecar3's proposed fix (#10800) fixes those cases 🎉

[designsimply]

Users affected in the last 90 days: 5200
_{https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/}

I can see the numbers of crashes diminishing in the Sentry Last 30 Days graph 🎉 but I am not sure at what point it's okay to close this issue.

[cameronvoell]

Here is another graph showing the effect of wordpress-mobile/gutenberg-mobile#1582 being released to the Play Store around November 30th.

In other graphs, you can see that we're still getting around 40-50 crashes per day with a similar stack trace, but I can not reproduce it with the steps mentioned in this issue so far.

I tried the steps outlined in this comment #10491 (comment) with most of the blocks mentioned there, and could not get a crash.

I noticed the prior fix for the crash produced by the steps outlined above seemed a little unintuitive without background info (adding OS: 'native', to our platform.android.js/platform.ios.js files). Perhaps @marecar3 or @SergioEstevao can weigh in on how this PR: https://github.com/WordPress/gutenberg/pull/18539/files fixed the majority of these crashes before, and whether that provides any hints into how we can fix, or find steps for the remaining 40-50 crashes happening per day with a similar stack trace.

[designsimply]

Events in the last 90 days: 13,000
Users affected in the last 90 days: 5,700
_{https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/}

[designsimply]

268 events have been tracked for this crash in 14.6.1 since it was released 9d ago on Apr 22.

Number of users affected in the last 90d: 3,400
_{https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/}

[designsimply]

759 events have been tracked for this crash in 14.7 and 14.7.1 since they were released 15d and 4d ago respectively.

Events in the last 90d: 17,000
Events in the last 15d for 14.7: 487
Events in the last 4d for 14.7.1: 272
Users affected in the last 90d: 3,900
Note: several Redmi devices are affected but I'm not sure if it's a significant enough number
_{https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/}

[designsimply]

Seeing an upward trend (not drastic but still) on this one in the last 90d, and the high volume of users affected is concerning.

[Tug]

We encountered that issue while testing. It's actually quite easy to reproduce:
From a blank page, add columns, a header block inside one column. Remove header block after focusing it, then focus on the column and tap the cog icon. You should experience it.

I was also able to experience it while testing the homepage for the vesta template, here's a quick video

[lukewalczak]

At first glance it's related to removing nested block based on RichText since I was not able to reproduce the crash via nesting and removing other blocks such as Code or Read More. Will continue the investigation

[AliYar-Khan]

this is happening again but I am using a native component ... while calling this UIManager.dispatchViewManagerCommand(this.handlerRef, "init", []); my app crashesh with same error