YouTube-based incremental video: YouTube IFrame Player API doesn't work in IE in a local environment

From SuperMemopedia
Jump to navigation Jump to search

Summary

SuperMemo 19 resolves issues of running YouTube in incremental video

SuperMemo 19 script can be reused in SuperMemo 18. SuperMemo 19 uses YouTube script named YouTube.htm in \bin folder, dated Dec 19, 2023. It runs from youtube.supermemo.org server.

As of Dec 1, 2017, SuperMemo 17 for Windows, version 17.3, uses the new YouTube API in incremental video script. This means that all posts related to problems with upgrading to new YouTube API are no longer relevant. The posts will be retained for archiving purposes, and for users of older versions of SuperMemo.

SuperMemo 17.3 uses a script named YouTube.htm in place of the old yt.htm which you can now delete (folder \bin). The new script is a stub that runs the actual script from supermemory.info server.

Privacy: We do not collect user data while running the script. The change of execution mode was caused by a bug in YouTube API for which we received no feedback from Google support in 12 months. The dependence on the server can be changed with one parameter in the script. You can run this script from your own server.

If you want to use new YouTube API in older SuperMemos, you will need to substitute your yt.htm script with the new version (see: Workaround). There are few minor issues with handling keyboard shortcuts though. Those hiccups have only be fully resolved in version 17.3.

As of Jul 1, 2018, SuperMemo 15 Freeware, version 15.5, uses the new YouTube API

For more see: Incremental Video

Intro

Supporting the current YouTube IFrame Player API for YouTube-based incremental video requires changes to SuperMemo that are not backward-compatible.

See also

See also:

Reason

In Internet Explorer, the YouTube IFrame Player API does not issue the onReady() event, i.e. the event which fires whenever a player has finished loading and is ready to begin receiving API calls, if it is run locally.

Question

Could this be caused by a setting in Internet Explorer itself? You say the problem with incremental video comes from a change in YouTube API. If so, I have the following questions:

  • why did the switch in the API coincide exactly with the update to Internet Explorer (including changes to security settings such as copying from the clipboard)(by "exactly", I mean: "down to a single showdown-restart cycle")
  • why does the YouTube player version=2 still work despite the changes in the API
  • why do local files with the new HTML YouTube API cause problems in Internet Explorer, while Chrome or Firefox have no issues?
  • could this be some outcome of Google-Microsoft wars? If so, who is the likely culprit?
  • should we all not bombard Google or Microsoft with complaints about this "progress"? if this is about their wars, why do users of SuperMemo suffer?

Explanation

There are a number of security restrictions that prevent http: and file: resources from talking to each other, both in the postMessage() JavaScript calls and in the Flash runtime

Question

If this is a discussion from 2012, it might be relevant to the old API. If so, how were the restrictions in the old JavaScript/Flash version resolved in SuperMemo? Perhaps we should keep posting and asking there for clear answers/solutions? If Jeff Posnick is from YouTube API Team, he might be the best person to ask (on behalf of all users of SuperMemo)!

Answer

No, it is not relevant to the old API. If you expand the very first message in the linked thread, you will discover it was related to the IFrame Player API, which, at that time, was at the experimental stage. Since then it has become the new recommended API superseding both Flash API (A3) and JavaScript API.

Nevertheless, a question asking to elaborate on the number of security restrictions was posted at Stack Overflow

Test case

The upgraded player with the minimum necessary implementation: http://supermemo.org/iv/IFramePlayerAPI.htm

Save it to a local hard drive, and open it from a disk in Internet Explorer. The video will load but the onReady() event will not be fired. Additionally, attempting to operate the player via the custom panel will throw a number of object doesn't support property or method errors wherever player API functions are used (e.g. ytplayer.getCurrentTime())

Puzzle 1

Do you guys know that the old YT.htm script fails the same test too? It works ok in SuperMemo though. I checked the code and noticed some strange value set for the videoid: value="zzzYT-IDzzz". When I put there the YouTube ID from your current script "eYqzcqDtL3k", it behaves all exactly like your new version! It needs to be started manually and buttons do not work. Are you sure your "test" is a valid measure of the problem?

Puzzle 2

This is not true in my case: attempting to operate the player via the custom panel will throw a number of object doesn't support property or method errors. I use IE11 in Win10. All settings are default except those needed to run SuperMemo (1-2 settings affair).

Solution

  1. Host the upgraded player online on a server (e.g. supermemo.org).
  2. Modify SuperMemo to load the remote player with relevant variables (e.g. video id, start, stop, and mark) passed as URL parameters

Pros and cons

Pros

  • Abandoning the deprecated JavaScript Player API (as of Aug 11, it does not work anyway)
  • HTML5-based player (no more resource-intesive Flash dependencies)
  • moving to an on-line web-based environment makes future backward-incompatibilities less likely
  • potentially better analytics (enabling the developer to have a peak how the feature is actually used)
  • leaner SuperMemo (e.g. no more need to hard-code the player)

Cons

  • Slower loading speed (the player will need to be retrieved from a server as opposed to being loaded from a local file)
  • external server dependency

Mitigating the external server dependency

  1. Open-source the new player at one of the public repositories (e.g. github.com)
  2. Make the player URL customizable via an INI setting

This way, any user will be free to check out the latest source code of the player, set it up on their server, and set SuperMemo to use the custom location instead of the default one.

Go for Vimeo!

Before you give up on the old solution, move the process to supermemo.org, and make users of older SuperMemo stranded, please consider the outcome of the following experiment. The old Flash-based yt.htm script from the BIN folder in SuperMemo has the same issues in Internet Explorer 11 as your new version! When I replace value="zzzYT-IDzzz" id="videoid" with an actual ID, e.g. value="UTMxfAkxfQ0" id="videoid", I can see that the video does not start in Internet Explorer. However, the same video plays ok in SuperMemo. An important twist now is the difference between versions of the player: 2 and 3 (playerapiid=ytplayer&version=2 and playerapiid=ytplayer&version=3):

  • version 2: plays in SuperMemo, does not play in IE11
  • version 3: does not play in SuperMemo, does not play in IE11 and shows the message "The YouTube Flash API was officially deprecated on January 27th, 2015."

In your question at Stackoverflow you say that Vimeo has a parallel implementation and it works ok. How about making it available for users of SuperMemo as a bonus. I am sure users would prefer good Vimeo and clumsy YouTube (as of now), over a long wait for working YouTube located at supermemo.org server with double server dependence (plus leaving older versions of SuperMemo on their own).

In addition to a Vimeo bonus for users of SuperMemo, you could spur YouTube to get their act together if you showcase superior Vimeo implementation! I am sure Google support will be quicker to act if you mention the neat solutions in the competitive camp!

Retrieved from "http://supermemopedia.com/index.php?title=YouTube-based_incremental_video:_YouTube_IFrame_Player_API_doesn%27t_work_in_IE_in_a_local_environment&oldid=24155"