gutenberg-mobile icon indicating copy to clipboard operation
gutenberg-mobile copied to clipboard

TypeError: `false` is not a function

Open fluiddot opened this issue 2 years ago • 14 comments

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

fluiddot avatar Nov 07 '23 10:11 fluiddot

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 avatar Nov 08 '23 19:11 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.

dcalhoun avatar Nov 10 '23 19:11 dcalhoun

Sentry issue: WORDPRESS-IOS-452F

sentry[bot] avatar Nov 29 '23 19:11 sentry[bot]

Sentry issue: JETPACK-IOS-14MW

sentry[bot] avatar Nov 29 '23 19:11 sentry[bot]

From further testing, my belief is that this crash and others (https://github.com/wordpress-mobile/gutenberg-mobile/issues/6127, https://github.com/wordpress-mobile/gutenberg-mobile/issues/6128, https://github.com/wordpress-mobile/gutenberg-mobile/issues/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 https://github.com/wordpress-mobile/gutenberg-mobile/issues/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 https://github.com/wordpress-mobile/gutenberg-mobile/issues/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 Xcode crash 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 avatar Dec 05 '23 18:12 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 Xcode shows additional stack trace details in the editor rather than the console log

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 https://github.com/wordpress-mobile/gutenberg-mobile/issues/6128. However, all of these issues (https://github.com/wordpress-mobile/gutenberg-mobile/issues/6127, https://github.com/wordpress-mobile/gutenberg-mobile/issues/6128, https://github.com/wordpress-mobile/gutenberg-mobile/issues/6203, https://github.com/wordpress-mobile/gutenberg-mobile/issues/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 avatar Dec 05 '23 18:12 dcalhoun

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

dcalhoun avatar Dec 20 '23 18:12 dcalhoun

Sentry issue: JETPACK-ANDROID-HRK

sentry[bot] avatar Jan 31 '24 10:01 sentry[bot]

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.

fluiddot avatar Jan 31 '24 10:01 fluiddot

Sentry issue: JETPACK-ANDROID-J1Z

sentry[bot] avatar Feb 07 '24 16:02 sentry[bot]

Sentry Issue: WORDPRESS-ANDROID-2VAA

sentry[bot] avatar Feb 14 '24 06:02 sentry[bot]

Sentry Issue: JETPACK-ANDROID-JM6

sentry[bot] avatar Feb 22 '24 09:02 sentry[bot]

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.

dcalhoun avatar Apr 01 '24 12:04 dcalhoun

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.

geriux avatar Apr 30 '24 10:04 geriux