GeezerVison is showing github.com — fix(android): don't crash in Fragment.onCreateView on stale-fragment race by NathanWalker · Pull Request #11264 · NativeScript/NativeScript
Conversation
NathanWalker
commented
Jun 9, 2026
•
edited by Copilot
AI
Loading
Uh oh!
There was an error while loading. Please reload this page.
onCreateView already returns null when its entry, resolvedPage, or frame is missing, but it first called Trace.error, which rethrows through the registered error handler across the JNI boundary and turns the recoverable case into a fatal "Calling js method onCreateView failed" crash.
These nulls happen when the FragmentManager drives a stale fragment to CREATE_VIEW after NativeScript has already torn down the corresponding backstack entry (process death / activity recreation after rotation or theme change, clearHistory, or rapid navigate+goBack). The fragment should just be discarded, not crash the app.
Replace those three Trace.error calls with Trace.write using Trace.messageType.error, and remove the Trace.isEnabled guards around those writes so the logs are always emitted while the existing return-null recovery path is still reached (consistent with existing onDestroy handling of the same race).
Fixes production crashlytics reports:
Fatal Exception: com.tns.NativeScriptException: Calling js method onCreateView failed
Error: fragment0[0]<null>.onCreateView: entry has no resolvedPage
at com.tns.Runtime.callJSMethodNative(Runtime.java)
at com.tns.Runtime.dispatchCallJSMethodNative(Runtime.java:1441)
at com.tns.Runtime.callJSMethodImpl(Runtime.java:1327)
at com.tns.Runtime.callJSMethod(Runtime.java:1314)
at com.tns.Runtime.callJSMethod(Runtime.java:1291)
at com.tns.Runtime.callJSMethod(Runtime.java:1287)
at com.tns.FragmentClass.onCreateView(FragmentClass.java:55)
at androidx.fragment.app.Fragment.performCreateView(Fragment.java:3119)
at androidx.fragment.app.FragmentStateManager.createView(FragmentStateManager.java:577)
at androidx.fragment.app.FragmentStateManager.moveToExpectedState(FragmentStateManager.java:286)
at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:2214)
at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:2109)
at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:2052)
at androidx.fragment.app.FragmentManager$5.run(FragmentManager.java:703)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7631)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:964)
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
…race
onCreateView already returns null when its entry, resolvedPage, or frame is
missing, but it first called Trace.error, which rethrows through the registered
error handler across the JNI boundary and turns the recoverable case into a
fatal "Calling js method onCreateView failed" crash.
These nulls happen when the FragmentManager drives a stale fragment to
CREATE_VIEW after NativeScript has already torn down the corresponding
backstack entry (process death / activity recreation after rotation or
theme change, clearHistory, or rapid navigate+goBack). The fragment should
just be discarded, not crash the app.
Downgrade the three guards to Trace.messageType.warn so the existing
return-null recovery path is actually reached, consistent with the existing
onDestroy handling of the same race.
nx-cloud
Bot
commented
Jun 9, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
|
View your CI Pipeline Execution ↗ for commit 26d34e1
| Command |
Status |
Duration |
Result |
nx test apps-automated -c=android |
✅ Succeeded |
3m 53s |
View ↗ |
nx run-many --target=test --configuration=ci --... |
✅ Succeeded |
<1s |
View ↗ |
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗
☁️ Nx Cloud last updated this comment at 2026-06-09 22:14:54 UTC
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
|
// Recoverable race: a stale fragment is being driven to onCreateView by the
|
|
|
// FragmentManager after its entry was cleared.
|
|
|
// Using Trace.error (routes to an error handler, which throws) would be fatal as the error handler rethrows across the JNI boundary.
|
|
|
if (Trace.isEnabled()) {
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@NathanWalker We can't ignore the possibility that it may also occur if something goes wrong.
If it occurs too frequently in your apps, it's a sign there's something we shall take care of.
I'd suggest we removed the isEnabled check and use messageType.error instead to let message be printed no matter what.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would work as well, will adjust 👍 (main thing is to avoid the trace.error there)
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
CatchABus reacted with thumbs up emoji
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@copilot please remove the isEnabled checks around the Trace.write in this PR and switch to Trace.messageType.error for each.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in 2b51674: removed the Trace.isEnabled() guards around those Trace.write calls and switched all three to Trace.messageType.error. I also added comment clarifications in 11902bc to make clear this remains non-fatal.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Reviewers
triniwiz
triniwiz approved these changes
+2 more reviewers
Reviewers whose approvals may not affect merge requirements
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
|