-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeError: false
is not a function
#6359
Comments
I spent time reviewing the history and logs for this crash. Capturing a few notes for posterity.
|
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 issue: WORDPRESS-IOS-452F |
Sentry issue: JETPACK-IOS-14MW |
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:
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
Suggested Next Steps
|
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). The symbolicated stack trace is attached below as well. It appears to point to the fact that Symbolicated stack trace for #6128
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. |
Random thought: I wonder if upgrading to React Native |
Sentry issue: JETPACK-ANDROID-HRK |
Extracted from the breadcrumbs of JETPACK-ANDROID-HRK, I noticed the following native error:
I wonder if this might be a clue to narrow down the culprit of the crash. |
Sentry issue: JETPACK-ANDROID-J1Z |
Sentry Issue: WORDPRESS-ANDROID-2VAA |
Sentry Issue: JETPACK-ANDROID-JM6 |
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. |
An attempt to fix this issue was shipped in |
Sentry Issue: JETPACK-ANDROID-HRK
Symbolicated stack trace:
Raw stack trace⤵️
The text was updated successfully, but these errors were encountered: