-
Notifications
You must be signed in to change notification settings - Fork 10
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
[BUG] [Android] Setting controls prop causes a crash: Null object reference in getPlayer() #121
Comments
You can change / patch
this will fix your issue. |
@chaimPaneth Reopening the ticket because:
|
@jakubjuraszek I'm unable to reproduce this issue. When I set I think the suggestion @chaimPaneth provided stops the crash, but whatever is causing this situation is blocking you from ever having the controls turned off. Another option is to hide all the "uiConfig": {
"hasOverlay": false,
"hasControlbar": false,
"hasCenterControls": false,
"hasNextUp": false,
"hasSideSeek": false,
"hasError": false,
"hasPlaylist": false,
"hasQualitySubMenu": false,
"hasCaptionsSubMenu": false,
"hasPlaybackRatesSubMenu": false,
"hasAudiotracksSubMenu": false,
"hasMenu": false,
"hasPlayerControlsContainer": false,
"hasCastingMenu": false,
"hasChapters": false,
"hasAds": false
} Can you provide the configuration you are using or more information on how to recreate the issue? |
@Jmilham21 code below. This is pure RN (0.73) app with JWPlayer 1.0.3.
|
I'll follow up when I get a chance to test. Thanks @jakubjuraszek |
Describe the bug
Setting the controls prop to any value other than undefined causes an application crash on Android with the following error:
To Reproduce
Expected behavior
The application should not crash when the controls prop is set. The player should properly initialize and display controls accordingly.
Screenshots / Visual evidence
Device(s) affected
Any Android (Emulator or real device)
Additional context
This issue seems to be related to the player instance not being initialized when the controls prop is set. A possible fix could involve ensuring getPlayer() is called only after proper initialization.
The text was updated successfully, but these errors were encountered: