Skip to content
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

Cannot read property 'length' of null when try to enable captioning #990

Closed
SemihGk opened this issue Aug 25, 2017 · 11 comments
Closed

Cannot read property 'length' of null when try to enable captioning #990

SemihGk opened this issue Aug 25, 2017 · 11 comments
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@SemihGk
Copy link
Contributor

SemihGk commented Aug 25, 2017

Have you read the FAQ and checked for duplicate issues:

What version of Shaka Player are you using:
2.2 (reproduced 2.1.x as well)

Can you reproduce the issue with our latest release version:
Yes.
Can you reproduce the issue with the latest code from master:
Yes
Are you using the demo app or your own custom app:
My custom app. I could not reproced the error on the demo app. Probably video contents in the demo app are not suitable for this error.

If custom app, can you reproduce the issue using our demo app:
No.

What browser and OS are you using:
Mac OS: 10.12.6
Chrome 60

What are the manifest and license server URIs:
(you can send the URIs to shaka-player-issues@google.com instead, but please use GitHub and the template for the rest)
If it's required, we can send the custom app.

What did you do?
Enabled captioning on and waited around a minute(time gap is unpredictable). Then, it caught the error when I tried to disable and enable again.

What did you expect to happen?
It should not throw an error.

What actually happened?
Video is stopped. Please check the screenshot. As you may see it in screenshot, It throws the error at lib/text/simple_text_displayer.js :231, cues.length . When 'cues' is null. I put a console.log to show it in screenshot as well.

screen shot 2017-08-25 at 12 07 48 pm

@ismena
Copy link
Contributor

ismena commented Aug 25, 2017

Hi @SemihGk, thanks for reporting.

Having access to the app/content would definitely help us figure out what's going on. Feel free to send it to shaka-player-issues@google.com.

@ismena ismena added the status: waiting on response Waiting on a response from the reporter(s) of the issue label Aug 25, 2017
@SemihGk
Copy link
Contributor Author

SemihGk commented Aug 25, 2017

Thank you for your prompt response. I just sent the app with its instructions. Please let me know if you need more information.

@joeyparrish joeyparrish added needs triage and removed status: waiting on response Waiting on a response from the reporter(s) of the issue labels Aug 25, 2017
@SemihGk
Copy link
Contributor Author

SemihGk commented Aug 25, 2017

I was testing the demo app and I could finally reproduce the error. Please check the screenshot:

Tested video: Sintel 4k (multicodec, VTT in MP4).

screen shot 2017-08-25 at 5 40 03 pm

@joeyparrish
Copy link
Member

Did you reproduce in the demo by turning captions on and off? Is it easier to reproduce in your own application than in the demo?

@SemihGk
Copy link
Contributor Author

SemihGk commented Aug 25, 2017

Yes, I turned captions on. Then, waited maybe 30 minutes. I replayed the video again and turned off and on several times. After these tries, I could reproduce it. It is definitely tough to reproduce in the demo. It is much easier to reproduce it in our app.

Edit: Reproduced again after I have done same steps, but this time video was not stopped.
screen shot 2017-08-25 at 6 37 19 pm

@vaage vaage self-assigned this Sep 5, 2017
@vaage
Copy link
Contributor

vaage commented Sep 5, 2017

A small update on this.

TextTrack.cues is only null when mode is set to "disabled". As we can see in the initial post, the current text track that the displayer is set to "disabled". This explains why we are getting a null list of cues.

What I am still looking into is why the track is being set to "disabled" in the first place. When toggling close captions on and off, the track is set to "hidden". So at some other point, someone is setting mode to "disabled".

@joeyparrish
Copy link
Member

@SemihGk, is your application directly manipulating the track state instead of using Player.setTextTrackVisibility()? Are you using custom video controls (video.controls == false) or the built-in browser controls (video.controls == true)?

It is possible that the browser built-in controls use "disabled" instead of "hidden".

@SemihGk
Copy link
Contributor Author

SemihGk commented Sep 5, 2017

Thank you for your responses, @vaage and @joeyparrish.

We did not set the mode to "disabled" in our application. Everything is just default. Also, same error is reproduced in the demo app. I assume demo app do not have any custom settings as well. It only happens when we turn captions on and off without changing any settings(including built-in browser controls).

@vaage
Copy link
Contributor

vaage commented Sep 5, 2017

@joeyparrish You are right. Once we change over to use the default browser built-in controls, it uses "disabled" instead of "hidden".

@SemihGk Thank you for bringing this to our attention. I will get a fix put together today.

@SemihGk
Copy link
Contributor Author

SemihGk commented Sep 5, 2017

Thank you, @vaage. We look forward to waiting the fix then.

@vaage vaage added type: bug Something isn't working correctly and removed needs triage labels Sep 6, 2017
@joeyparrish joeyparrish added this to the v2.3.0 milestone Sep 6, 2017
@joeyparrish
Copy link
Member

This will be cherry-picked to v2.2.2.

joeyparrish pushed a commit that referenced this issue Sep 26, 2017
When a text track's mode is set to "disabled" the cues exposed cue
list is set to null. However, if you save a reference to the list,
the reference is valid. If the track is disabled, the add and remove
calls still work.

This change caches the reference to the cue's list when the track is
first created so that we can always read it - regardless of what mode
the track is set to.

Fix #990

Change-Id: I8274ea8450e664eeaa359bf9e78d13405fd2e503
@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

5 participants