This one started on 11.9 and seems to be related to React. It has been pretty common in all the subsequent version and had a weird spike a couple of days ago.
React Native side of the stacktrace:
Fatal Exception: com.facebook.react.common.JavascriptException: TypeError: undefined is not an object (evaluating 'n.url.indexOf')
This error is located at:
in h
in u
in WithFilters(u)
in F
in RCTView
in RCTView
in TouchableWithoutFeedback
in t
in P
in WithDispatch(t)
in b
in WithSelect(WithDispatch(t))
in RCTView
in RCTView
in c
in RCTView
in c
in RCTView
in RCTScrollView
in E
in z
in _
in RCTView
in _
in f
in c
in RCTView
in RCTView
in h
in p
in P
in WithDispatch(p)
in b
in WithSelect(WithDispatch(p))
in S
in h
in WithRegistry(h)
in P
in WithDispatch(WithRegistry(h))
in o
in P
in WithDispatch(o)
in b
in WithSelect(WithDispatch(o))
in s
in p
in RCTView
in RCTView
in c, stack:
value@1308:1290
Ji@100:67747
ea@100:69782
<unknown>@100:81296
unstable_runWithPriority@178:3238
ja@100:81253
Oa@100:81007
Wa@100:80310
Aa@100:79323
sa@100:78013
Ba@100:82505
render@100:85076
exports@351:592
run@347:615
runApplication@347:2017
value@51:3311
<unknown>@51:822
value@51:2565
value@51:794
and the native side stacktrace:
#0. Crashed: mqt_native_modules
at com.facebook.react.modules.core.ExceptionsManagerModule.showOrThrowError(ExceptionsManagerModule.java:54)
at com.facebook.react.modules.core.ExceptionsManagerModule.reportFatalException(ExceptionsManagerModule.java:38)
at java.lang.reflect.Method.invoke(Method.java)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:158)
at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:154)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
at java.lang.Thread.run(Thread.java:761)
5bd5cd39f8b88c29638eaf23-fabric
Updated the ticket description to include the React Native side stacktrace as well.
30-day impact: ~35 per day
Users affected: 343
First seen in: 11.9
Last seen in: 12.3 (current release)
(5bd5cd39f8b88c29638eaf23-fabric-android)
I'm still investigating this, and so far, I suspect this could be coming from this line: https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/image/edit.native.js#L85. I'm going to explore the code paths that reach that point to see if I can create steps to reproduce this.
The only other place I could find a similar reference of [some variable].url.indexOf was here:
https://github.com/WordPress/gutenberg/blob/master/packages/api-fetch/src/middlewares/fetch-all-middleware.js#L35, but it could not have been the cause, as: if options.url was undefined, the && operator would short-circuit to false.
I believe I have found a way to reproduce this. If an image upload is cancelled, attributes.url will be set to null here: https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/image/edit.native.js#L162. Subsequently leaving the editor and coming back to the editor will thus trigger the rendering of the image component _with_ an id, but _without_ a url, leading to the crash. After the local draft is in this state, every attempt to access it via the editor will lead to a crash.
Steps to reproduce:
For step 4, it may help to use a large image file, or if you are using an emulator, to slow down the internet connection to make it easier to cancel the upload before it finishes.
30-day impact: ~2.3 per day
Users affected: 20 in the last 30d
Last seen in: 12.2 (according to the linked fabric report)
5bd5cd39f8b88c29638eaf23-fabric
@mkevins what are your thoughts on whether to keep this issue open now that it looks like the occurrences have gone way down and only seem to be happening for older releases?
@mkevins what are your thoughts on whether to keep this issue open now that it looks like the occurrences have gone way down and only seem to be happening for older releases?
Hi @designsimply :wave: I think it's safe to close, as the fix seems to have been effective for this one. :tada: Thanks for circling back to provide the stats! :smiley: