Describe the bug
In ios/RNJWPlayer/RNJWPlayerView.swift, setConfig has a branch for the case where only the playlist key differs (lines 297–365). That branch applies the new playlist but never assigns currentConfig.
Every other apply path does assign it — lines 627, 715, 752 and 889.
After a playlist-only update the module's cached config therefore still describes the previous playlist, so the next setConfig diffs the incoming config against a configuration that was never the one applied.
To Reproduce
- Set up a player with an array
config.playlist.
- Change only
config.playlist (e.g. reorder the items).
- Observe that
currentConfig is unchanged, while the player has been sent the new playlist.
Expected behavior
currentConfig reflects whatever was last applied, consistently across all apply paths.
Additional context
We have not traced a user-visible symptom to this on its own, so filing it as a correctness issue rather than a defect report. It surfaced while investigating #248, and it makes reasoning about that branch harder because the module's own record of state is unreliable.
Looks like a one-line fix.
Unchanged in 1.7.0 and on main.
Describe the bug
In
ios/RNJWPlayer/RNJWPlayerView.swift,setConfighas a branch for the case where only theplaylistkey differs (lines 297–365). That branch applies the new playlist but never assignscurrentConfig.Every other apply path does assign it — lines 627, 715, 752 and 889.
After a playlist-only update the module's cached config therefore still describes the previous playlist, so the next
setConfigdiffs the incoming config against a configuration that was never the one applied.To Reproduce
config.playlist.config.playlist(e.g. reorder the items).currentConfigis unchanged, while the player has been sent the new playlist.Expected behavior
currentConfigreflects whatever was last applied, consistently across all apply paths.Additional context
We have not traced a user-visible symptom to this on its own, so filing it as a correctness issue rather than a defect report. It surfaced while investigating #248, and it makes reasoning about that branch harder because the module's own record of state is unreliable.
Looks like a one-line fix.
Unchanged in
1.7.0and onmain.