shaka.text.SimpleTextDisplayer is not a constructor

Have you read the FAQ and checked for duplicate open issues?

Yes. Searched issues, read release notes of 2.5.0-beta3 and plugins page/doc around text displayer.

What version of Shaka Player are you using?

2.5.0-beta3

Can you reproduce the issue with our latest release version?

With 2.5.0-beta3.

Can you reproduce the issue with the latest code from master?

With 2.5.0-beta3.

Are you using the demo app or your own custom app?

Custom app.

If custom app, can you reproduce the issue using our demo app?

No.

What browser and OS are you using?

Chrome/OSX.

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

NA.

What are the manifest and license server URIs?

Happens when calling the constructor of shaka.Player

What did you do?

const shakaPlayer = new ShakaPlayer(/** @type {!HTMLMediaElement} */
    (videoElement));

What did you expect to happen?

No exception in console log.

What actually happened?

After upgrading from 2.5.0-beta2 to beta3 without any other changes, I see an exception prompted to the console. The playback works as expected though, when continuing and/or I found some workarounds but I wanted to report (not sure about subtitles yet).

It appears to me that the js compiler concatenates the javascript differently then with beta2. With beta3 the SimpleTextDisplayer is now appended at the very end of the concatenated javascript file. This seems to be outside the closure dependency system, so when I start our app and construct Shaka the SimpleTextDisplayer is not available in shaka.Player.prototype.defaultConfig_:L2417 which causes this stack trace:

app_desktop.js:46803 Uncaught (in promise) TypeError: shaka.text.SimpleTextDisplayer is not a constructor
    at new config.textDisplayFactory (app_desktop.js:46803)
    at shaka.Player.createMediaSourceEngine (app_desktop.js:45598)
    at shaka.Player.attach (app_desktop.js:44987)
    at new shaka.Player (app_desktop.js:44591)
    at app_desktop.js:50363
    at Object.goog.loadModule (app_desktop.js:1170)
    at app_desktop.js:50212

I can avoid this stack trace constructing Shaka in an async function like with setTimeout or onload=() => {}. This makes me constructing Shaka in the next looper event, when shaka.text.SimpleTextDisplayer will available because the js has been interpreted to the very end.

I can actually imagine this is WAI and I need to adjust my build somehow. I’d prefer though, having this working inside the closure dependency system instead of the asyn onload thingy.

So if WAI, what is the recommended tweak? Should I just require shaka.text.SimpleTextDisplayer somewhere in my code just to make the compiler concatenated it before I construct Shaka? Or can Shaka require it to use it safely in shaka.Player.prototype.defaultConfig_:L2417?

A temporary workaround which works is requiring the SimpleTextDisplayer:

const SimpleTextDisplayer = goog.require('shaka.text.SimpleTextDisplayer');
// ... code, code, code
new SimpleTextDisplayer(mediaElement); // avoid lint warnings
new ShakaPlayer(mediaElement);

This makes the compiler concatenated the SimpleTextDisplayer earlier.

[joeyparrish]

Using the exact tag v2.5.0-beta3, I can’t reproduce your results with the sample application in our “basic usage” tutorial. I see no exception, and I can display subtitles by running:

player.selectTextTrack(player.getTextTracks()[0]);
player.setTextTrackVisibility(true);

So the text displayer is working properly.

Two things worth noting, though:

1. The sample app waits for document’s DOMContentLoaded event before constructing a Player instance. In general, you should probably be waiting for some event to know that your JS is fully loaded and that the necessary DOM elements are available. If you aren’t doing that, this could be the key difference between your app and mine.
2. Although Player references SimpleTextDisplayer, it doesn’t goog.require it. This would cause issues with the dependency ordering in the compiler, which would explain how beta2 and beta3 differ. This is a bug on us, but one you should be naturally working around by waiting for some appropriate event as described above.

The missing goog.require is a pretty trivial fix, so I’ll get that done right now.

[marcbaechinger]

Thanks all! I can confirm your findings. Both approaches work for me.

I prefer relying on the dependency ordering only, so I was able to workaround it by requiring SimpleTextDisplayer in my code and do nothing with it just to have the dependency ordering differently as you mention in 2. above.

Thanks for adding the goog.require, that’s the best solution for me.