Updated player.ready to always be async

[heff]

Addresses #1667

I've changed ready() and triggerReady() to always be async. However now a bunch of track tests are falling.

@gkatsev, can you provide any insight here? I would guess it has to do with the text track display.

video.js/src/js/tracks/text-track-display.js

Line 41 in 1ff361a

player.ready(Fn.bind(this, function() {

Text Track Controls should be displayed when text tracks list is not empty FAILED
  control is displayed
  textTracks contains one item. Expected: 1 Actual: 0

If I move the addRemoteTextTrack part out of the ready listener the tests actually pass, but then other tracks tests fail.

Tracks TextTrackDisplay initializes tracks on player ready FAILED
  TypeError: Cannot read property 'tracks' of undefined

[gkatsev]

It probably has to do with the workarounds I've done previously to get around the fact that html5 is sync and flash is async.

[gkatsev]

Also, code-wise, LGTM

[gkatsev]

kill those for-loops with extreme prejudice! :D

[heff]

➰ 🔫 🙀

[gkatsev]

Also, didn't someone say that text tracks are generally broken in master, currently? Possibly related to that as well.

[gkatsev]

It's possible that we can remove the player.ready() wrapped for tracks and then just remove the test that checks that tracks are created on ready. I think that was one of my workarounds for this.

[gkatsev]

Ah, I know what the fix for the tests is. We need to actually trigger ready by ticking the clock forward.

[gkatsev]

I have a PR against this that fixes the text track errors: heff#9

[heff]

Thanks! Nice use of the PR PR. :)

I tried that with one test but only ticked 1ms, which apparently isn't enough even though ready() waits 1ms. Guess it's safer to be more liberal with the time.

Tests are passing now. Attempting to remove the ready listener now.

[heff]

Removed it and it's just the one test breaking now that tests specifically for that (like you said). Killing that test.

[heff]

@dmlap, I had this change in there but then decided to hold on it until we figured out how we wanted to handle tech changes. I forget where we landed, but also realized that the readyQueue does reset itself after ready is triggered, so ready listeners won't fire again on a tech change. That is, unless you listen for the ready event, not pass the function to ready(fn).

But basically the ready event was meant to let you add new ready listeners when the tech changes, it just may not be so clear that's the purpose. Maybe a techloaded event is the answer.