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
@daniloercoli do you think this is related to #8838 ?
90-day impact: ~23 per day
Users affected in the last 90 days: 1600
https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/
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)
90-day impact: ~32 per day
Users affected in the last 90 days: 2200
https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/
90-day impact: ~41 per day
Users affected in the last 90 days: 2500
https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/
I was able to reproduce this bug on both emulator and my hw device.

Emulator API 28
Pixel 3 API 29
Looks similar to https://github.com/wordpress-mobile/WordPress-Android/issues/8838
Full error stack trace in case it'd be useful
https://justpaste.it/57ypn
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
Steps to repro - Case B
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.
Hey @designsimply it seems that it's very similar to: https://github.com/wordpress-mobile/gutenberg-mobile/issues/1549
Yes! It does! I'll close https://github.com/wordpress-mobile/gutenberg-mobile/issues/1549 in favor of this issue. Thank you @marecar3!
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:
Results:
SOME_NEW_BLOCK | Result | Result after tapping inner EditText
-|-|-
Paragraph | :heavy_check_mark:
Heading | :heavy_check_mark:
Image | :boom: | :heavy_check_mark:
Video | :boom: | :heavy_check_mark:
List | :heavy_check_mark:
Quote | :heavy_check_mark:
Code | :heavy_check_mark:
More | :boom:
Page Break | :boom:
Separator | :boom:
Media & Text | :boom: | :heavy_check_mark:
Group | :boom:
Spacer | :boom:
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.
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 (https://github.com/wordpress-mobile/WordPress-Android/pull/10800) fixes those cases 馃帀
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.

I can confirm that this issue was most probably fixed in 13.8. I'm closing it for now, we can reopen it, if it appears again in version >=13.8.
It seems it still sometime crashes in 13.8. However, the frequency went down significantly. I'm reopening the issue for transparency, but I'd suggest checking the number of occurrences in version 13.8+13.9 in about 3 weeks and reconsider whether it's even worth fixing.
Users affected in the last 90 days: 5400
https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/
Here is another graph showing the effect of https://github.com/wordpress-mobile/gutenberg-mobile/pull/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 https://github.com/wordpress-mobile/WordPress-Android/issues/10491#issuecomment-554217851 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.
Events in the last 90 days: 13,000
Users affected in the last 90 days: 5,700
https://sentry.io/share/issue/132814a30e254edf9689f79eb92fb9c7/
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/
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/
Seeing an upward trend (not drastic but still) on this one in the last 90d, and the high volume of users affected is concerning.

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

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_
Most helpful comment
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.