TypeError: false is not a function

[fluiddot]

Sentry Issue: JETPACK-ANDROID-HRK

Symbolicated stack trace:

gutenberg/node_modules/react-native/Libraries/Pressability/Pressability.js:758:_performTransitionSideEffects
gutenberg/node_modules/react-native/Libraries/Pressability/Pressability.js:695:_receiveSignal
gutenberg/node_modules/react-native/Libraries/Pressability/Pressability.js:525:responderEventHandlers.onResponderRelease
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:22:invokeGuardedCallbackImpl
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:40:invokeGuardedCallback
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:53:invokeGuardedCallbackAndCatchFirstError
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:73:executeDispatch
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1125:executeDispatchesAndReleaseTopLevel
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:361:forEachAccumulated
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1160:batchedUpdates$argument_0
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:8457:batchedUpdatesImpl
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1106:batchedUpdates
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1137:_receiveRootNodeIDEvent
gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1209:ReactNativePrivateInterface.RCTEventEmitter.register$argument_0.receiveTouches
gutenberg/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:427:__callFunction
gutenberg/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:113:__guard$argument_0
gutenberg/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:368:__guard
gutenberg/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:112:callFunctionReturnFlushedQueue

Raw stack trace ⤵️

value@1:436892
value@1:436464
onResponderRelease@1:435281
c@1:359373
m@1:359430
v@1:359462
w@1:359594
Le@1:363833
$@1:361102
anonymous@1:364185
Ce@1:421849
Ne@1:363753
Me@1:364026
receiveTouches@1:416736
value@1:166857
anonymous@1:165357
value@1:166303
value@1:165315

[dcalhoun]

I spent time reviewing the history and logs for this crash. Capturing a few notes for posterity.

• The crash occurs for both posts and pages.
• The largely occurs on low- and medium-end devices, 62% and 23% respectively.
• The crash often times occurs immediately after the insertion of a block, but not always.
• Some crashes occur after several editor open and close events.
• Some crashes are preceded by performance warnings, e.g. Timeout reached before response from requestGetHtml, EditPostRepository: Transaction is writing on a locked thread.

[dcalhoun]

After spending more time debugging this, I am still unable to reproduce the error.

For next steps, I plan to implement a few more block editor analytic events to see if they help uncover any specific actions that correlate with this error. In the meantime, I will keep myself assigned to this issue as the DRI, but I do not plan to debug it further at this time.

[sentry-io]

Sentry issue: WORDPRESS-IOS-452F

[sentry-io]

Sentry issue: JETPACK-IOS-14MW

[dcalhoun]

From further testing, my belief is that this crash and others (#6127, #6128, #6203) may relate to performance issues. Specifically, posts with a good number of images often slow or hangs when attempting to persist the post content via the Update or Save buttons.

Before or during this period of a hanging app, one can queue up several actions by tapping various UI element — moving blocks, opening block settings, inserting blocks, etc. My belief is that these queued actions could ultimately be executed against incorrect or nonexistent blocks once the app resumes and the various logic for each interaction are finally executed.

I was able to twice reproduce a crash with a similar stack trace to #6128 with the following:

1. Open a post with a few text blocks and a lot of images (e.g. 3 galleries of 90+ images each).
2. Make a text modification to mark the post as "dirty."
3. Focus an image block and attempt to open the block settings.
4. Before the block settings opens, tap the "Update" button to save the post's content.

Once the persisting the post updates finished, the app attempted to open the block settings and threw the crash referenced in #6128. Unfortunately, while the stack trace resembles the crash, it does not include the details required (line numbers) for symbolicating the stack trace.

Crash Stack Trace

Unhandled JS Exception: TypeError: Cannot read property 'name' of null

This error is located at:
    in k
    in RCTView
    in Unknown
    in o
    in RCTView
    in Unknown
    in S
    in S
    in v
    in InspectorControlsSlot
    in Unknown
    in RCTView
    in Unknown
    in RCTView
    in Unknown
    in T
    in Unknown
    in RCTScrollContentView
    in RCTScrollView
    in O
    in ScrollView
    in h
    in Unknown
    in Unknown
    in Unknown
    in RCTView
    in Unknown
    in RCTView
    in Unknown
    in RCTView
    in Unknown
    in Unknown
    in RCTView
    in Unknown
    in A
    in Unknown
    in PanGestureHandler
    in Unknown
    in RCTView
    in Unknown
    in A
    in Unknown
    in RCTView
    in Unknown
    in T
    in Unknown
    in RCTView
    in Unknown
    in A
    in Unknown
    in u
    in u
    in Unknown
    in RCTView
    in Unknown
    in ScreenContainer
    in Unknown
    in RCTView
    in Unknown
    in Unknown
    in T
    in RCTView
    in Unknown
    in h

Xcode Screenshot

Suggested Next Steps

• Profile posts with a large number of images to understand where most of the time is spent, e.g. JavaScript thread vs native threads.
• Continue attempting to reproduce various crashes during app hangs by interacting with various UI elements for various block types.

[dcalhoun]

An update regarding the stack trace: I was able to symbolicate the stack trace after discovering the additional details are available in Xcode when clicking the "hamburger menu" icon next to the crash (captured in an image below).

Xcode Crash Details

The symbolicated stack trace is attached below as well. It appears to point to the fact that getBlock returns null (which is possible) and we attempt to access a name attribute on the null block.

Symbolicated stack trace for #6128

This error is located at:
    in k
    in RCTView
    in Unknown
    in o
    in RCTView
    in Unknown..., stack:
/workdir/gutenberg/packages/block-editor/src/components/block-styles/index.native.js:28:selector
/workdir/gutenberg/packages/data/src/components/use-select/index.js:134:registry.__unstableMarkListeningStores$argument_0
/workdir/gutenberg/packages/data/src/registry.js:123:__unstableMarkListeningStores
/workdir/gutenberg/packages/data/src/registry.js:204:<anonymous>
/workdir/gutenberg/packages/data/src/components/use-select/index.js:133:updateValue
/workdir/gutenberg/packages/data/src/components/use-select/index.js:180:<anonymous>
/workdir/gutenberg/packages/data/src/components/use-select/index.js:205:useMappingSelect
/workdir/gutenberg/packages/data/src/components/use-select/index.js:294:useSelect
/workdir/gutenberg/packages/block-editor/src/components/block-styles/index.native.js:33:BlockStyles
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:3525:renderWithHooks
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:4491:updateFunctionComponent
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:7850:beginWork$1
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:7304:performUnitOfWork
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:7297:workLoopSync
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:7279:renderRootSync
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:6975:performSyncWorkOnRoot
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:2145:flushSyncCallbacks
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:6650:scheduleUpdateOnFiber
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:3767:forceStoreRerender
/workdir/gutenberg/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:3752:subscribe$argument_0
/workdir/gutenberg/packages/data/src/components/use-select/index.js:69:onStoreChange
/workdir/gutenberg/packages/data/src/components/use-select/index.js:76:onChange
/workdir/gutenberg/packages/data/src/registry.js:247:currentSubscribe$argument_0
/workdir/gutenberg/packages/data/src/redux-store/index.js:351:store.subscribe$argument_0
/workdir/gutenberg/node_modules/redux/lib/redux.js:304:dispatch
/workdir/gutenberg/packages/data/src/redux-store/thunk-middleware.js:7:<anonymous>
/workdir/gutenberg/packages/redux-routine/src/index.js:24:<anonymous>
/workdir/gutenberg/packages/data/src/promise-middleware.js:20:<anonymous>
/workdir/gutenberg/packages/data/src/resolvers-cache-middleware.js:45:<anonymous>
/workdir/gutenberg/packages/data/src/redux-store/index.js:224:Proxy$argument_1.apply
/workdir/gutenberg/packages/core-data/src/actions.js:428:<anonymous>
/workdir/gutenberg/packages/data/src/redux-store/thunk-middleware.js:4:<anonymous>
/workdir/gutenberg/packages/redux-routine/src/index.js:24:<anonymous>
/workdir/gutenberg/packages/data/src/promise-middleware.js:20:<anonymous>
/workdir/gutenberg/packages/data/src/resolvers-cache-middleware.js:45:<anonymous>
/workdir/gutenberg/packages/data/src/redux-store/index.js:204:<anonymous>
/workdir/gutenberg/packages/editor/src/store/actions.js:139:<anonymous>
/workdir/gutenberg/packages/data/src/redux-store/thunk-middleware.js:4:<anonymous>
/workdir/gutenberg/packages/redux-routine/src/index.js:24:<anonymous>
/workdir/gutenberg/packages/data/src/promise-middleware.js:20:<anonymous>
/workdir/gutenberg/packages/data/src/resolvers-cache-middleware.js:45:<anonymous>
/workdir/gutenberg/packages/data/src/redux-store/index.js:204:<anonymous>
/workdir/gutenberg/packages/editor/src/store/actions.js:534:<anonymous>
/workdir/gutenberg/packages/data/src/redux-store/thunk-middleware.js:4:<anonymous>
/workdir/gutenberg/packages/redux-routine/src/index.js:24:<anonymous>
/workdir/gutenberg/packages/data/src/promise-middleware.js:20:<anonymous>
/workdir/gutenberg/packages/data/src/resolvers-cache-middleware.js:45:<anonymous>
anonymous"

To be clear, this finding is not a resolution to this issue. It relates more to #6128. However, all of these issues (#6127, #6128, #6203, #6359) still seem related to poor editor performance from my perspective. My thought is that a race condition exists that is exasperated by a hanging editor with low performance.

[dcalhoun]

Random thought: I wonder if upgrading to React Native >=0.72 will provide additional, helpful details for cryptic errors like this one.

[sentry-io]

Sentry issue: JETPACK-ANDROID-HRK

[fluiddot]

Extracted from the breadcrumbs of JETPACK-ANDROID-HRK, I noticed the following native error:

e/WordPress-EDITOR: Illegal selection index for text with length 12, selectionStart: 13, selectionEnd: 13, with UnknownHtmlSpan tags: []
e/WordPress-EDITOR: StackTrace: org.wordpress.mobile.ReactNativeAztec.IllegalSelectionIndexException: Illegal selection index for text with length 12, selectionStart: 13, selectionEnd: 13, with UnknownHtmlSpan tags: []
	at org.wordpress.mobile.ReactNativeAztec.ReactAztecManager.updateSelectionIfNeeded(ReactAztecManager.java:257)
	at org.wordpress.mobile.ReactNativeAztec.ReactAztecManager.setTextfromJS(ReactAztecManager.java:239)
	at org.wordpress.mobile.ReactNativeAztec.ReactAztecManager.setText(ReactAztecManager.java:220)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateViewProp(ViewManagersPropertyCache.java:93)
	at com.facebook.react.uimanager.ViewManagerPropertyUpdater$FallbackViewManagerSetter.setProperty(ViewManagerPropertyUpdater.java:136)
	at com.facebook.react.uimanager.ViewManagerPropertyUpdater.updateProps(ViewManagerPropertyUpdater.java:56)
	at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:86)
	at com.facebook.react.uimanager.NativeViewHierarchyManager.updateProperties(NativeViewHierarchyManager.java:142)
	at com.facebook.react.uimanager.UIViewOperationQueue$UpdatePropertiesOperation.execute(UIViewOperationQueue.java:93)
	at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:915)
	at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:1026)
	at com.facebook.react.uimanager.UIViewOperationQueue.access$2600(UIViewOperationQueue.java:47)
	at com.facebook.react.uimanager.UIViewOperationQueue$DispatchUIFrameCallback.doFrameGuarded(UIViewOperationQueue.java:1086)
	at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.java:29)
	at com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher.doFrame(ReactChoreographer.java:175)
	at com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1.doFrame(ChoreographerCompat.java:85)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1090)
	at android.view.Choreographer.doCallbacks(Choreographer.java:893)
	at android.view.Choreographer.doFrame(Choreographer.java:809)
	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1078)
	at android.os.Handler.handleCallback(Handler.java:907)
	at android.os.Handler.dispatchMessage(Handler.java:105)
	at android.os.Looper.loop(Looper.java:216)
	at android.app.ActivityThread.main(ActivityThread.java:7625)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:524)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:987)

I wonder if this might be a clue to narrow down the culprit of the crash.

[sentry-io]

Sentry issue: JETPACK-ANDROID-J1Z

[sentry-io]

Sentry Issue: WORDPRESS-ANDROID-2VAA

[sentry-io]

Sentry Issue: JETPACK-ANDROID-JM6

[dcalhoun]

Removing my assignment as I do not intend to work on this for the foreseeable future.

Our latest plan for addressing this crash was seeing if the React Native 0.73 upgrade provided additional clues for the origin of this crash.

[geriux]

An attempt to fix this issue was shipped in 24.7. So far there are no reported events but I'll continue to monitor the release to see if we can considered this as fixed.