[Architecture] Issues with YouTube captions enactor for UIO+

Obara, Justin jobara at ocadu.ca
Tue Jul 31 15:59:28 UTC 2018

Hello everyone,

For UIO+ I’ve recently been working on a feature to enable/disable captions in embedded YouTube videos. The initial implementation of this was to use YouTube’s iframe API<https://developers.google.com/youtube/iframe_api_reference> to be able to control the features of the embedded video. I was able to get this working in the standard UIO, site integrated, context. This work can be viewed as a PR to Infusion ( https://github.com/fluid-project/infusion/pull/914 ).

This week I’ve been attempting to integrate this work into UIO+ but am running into some issues trying to access the YT.Player created by the YouTube iframe API. It appears that the issue occurs because the JavaScript run in the web page context is run in a separate JavaScript environment than the JavaScript run from the injected content scripts<https://developer.chrome.com/extensions/content_scripts> used by the UIO+ extension.

The YouTube iframe API is provided as an external reference. Typically the documentation suggests that you use script injection on your web page, although it also works by just directly adding the necessary script tag ahead of time; which I’ve done in the example in my branch. However, YouTube’s iframe API itself performs script injection to get additional resources. It appears that these script injections will place their related JavaScript into the web page's JavaScript environment instead of the content scripts'.

If you have any suggestions or feedback on how to best solve this, I’d really appreciate it. Below are some ideas and potential work arounds.

1) Fork the YouTube iframe API and pull in static copies of remote resources to serve through the extension

This seems to be the most brittle solution. It doesn’t appear that we can get versioned copies of their API and any code we pull in could stop working at any time. That’s in addition to typical issues with forking code bases. The forking would be to modify the initial script to not do any script injection for the subsequent script that is required.

2) Offload the caption enactor and other communication features to be script injected.

The idea here is to shift more of the code to run in the web page context. We’d move the captions enactor there, in addition to the YouTube iframe API, and also the infrastructure for communicating between the web page context and content scripts. The communication can happen through a system of message posting<https://developer.chrome.com/extensions/content_scripts#host-page-communication>.

This is likely the most complex to set up and may require us to host some of our resources (e.g. the enactor and messaging system) on a CDN to use script injecting to push into the web page from the extension.

3) Skip the YouTube iframe API and attempt to interact with the DOM elements from the embedded video.

We’d inject the content script for the enactor into the YouTube videos iframe and look for the button element with the class "ytp-subtitles-button”. From there we’d icheck its aria-pressed attribute to see if the captions are enabled or not. There is no aria-pressed state if the video doesn’t support captions, or if it hasn’t started playing yet. So we’ll have to wait (listen/watch) for changes to this element to see what state it is actually in. When the we see that it is in the “wrong” state, we’ll programatically click the button and hope that it triggers the video player to toggle the captions.

Of course this is also brittle because the class name or other important aspects of the layout could change at any time.

For all of these options we’d really need to test them to make sure that they would actually work. They are just ideas at this point, but I’d like to thank Cindy for helping me talk through the issue and come up with these potential approaches.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20180731/f19e8201/attachment.html>

More information about the Architecture mailing list