Auto-advance Video and MFE

I’ve been implementing a custom video xblock borrowing patterns from the native video block. While doing this I noticed the auto-advance feature in the native video xblock is broken in my dev environment which has mfe enabled. I’m using tutor==14.0.4.

Based on my reading of the code, the way the auto-advance feature is supposed to work is by triggering a click event on the next button whenever a video completes, but because the MFE loads the unit content into an iframe the next button is not found. Increasing the complexity is the fact that the iframe loads the unit content from a different domain than the parent frame (at least in my dev environment, I haven’t tested this in a production environment). Because of this, the child frame doesn’t have direct access to the parent frame. The only way around issues like this that I am aware of is by using postMessage in the js of the xblock to post a message to the parent window when the video completes and move to the next page in an event listener on the parent window.

Questions:
Is this a known issue or a problem with my development setup?
If it is a known issue, is there work underway to address the problem that I can watch?
Are there any recommended approaches that differ from what I describe above?

I don’t know the answer of these two questions.

I think your overall conculsion is correct. To add to your point, when you are viewing a unit, from the learning MFE. there is a spesfic view/template which is called courseware-chromeless.html (code)["," % if section_title:","${static.get_page_title_breadcrumbs(section_title, course_name())}"," % else:","${static.get_page_title_breadcrumbs(course_name())}"," %endif","]. If you dig deep into code, you will see that there are a couple of events/callbacks where the parent (learning MFE) communicate with the unite(iframe). That being said, I would say there are a couple of things and ways to resolve your issue. Below is one of them but please don’t think of it as the ultimate or best solution:

On the MFE side:

In the iframe/unit side:

  • Either edit the xmodule (which you point above) or the chromeless template I linked earlier… so that it would send the parent window an event when its completed. Ideally I would say, you would edit the xmodule, so that if its running normal context, do what it do, and if its running in an iframe, send an event to parent instead… (But I really not sure if that would really work. Good question to ask is would that xmodule you pointed to would load in if its in an iframe?)

Lastly I think if you find a clean and efficent way to resolve this, then you could push it back upstream so everyone would benefit from it and you wouldn’t maintain a fork repos. But since I am not a maintainer of either repos so take my point with a grain of salt.

Hi @tramck!

I’m not sure if this issue has been considered by the authors of frontend-app-learning yet, but I was able to reproduce it on a devstack (as opposed to Tutor). And looking at the code, there’s indeed no way that will work in the Learning MFE.

Which is to say, this is an issue, but as far as I can tell not a previously known one (or at least, not a publicly acknowledged one). If there is work being done to fix it, I’m not aware of it.

You’re on the right track. Posting messages from the iframe up to the parent is how this has been handled in other cases. @ghassan’s suggestion above is a good one.

If you do go down this route, it will require modifying frontend-app-learning. It would be awesome if you could contribute those changes back: if the PR is accepted, we can then make corresponding changes to the existing Video XBlock so that auto advancing can work for everybody again!

Thanks for bringing this up, by the way. (Particularly since you clearly spent the time to research the problem beforehand: that makes it a lot easier to help!)

@ghassan @arbrandes Thank you! I appreciate the thoughtful answers. Currently, I am building a custom video xblock and will be working on a custom learning mfe soon, but with the guidance you’ve provided here and with the lessons I learn from working in my custom components, I will look into updating the open source repos when time allows.

1 Like

Hi @tramck & @arbrandes
The video xBlock was created before I came onboard with edX as Accessibility Specialist, and no one has complained about the current config (that I’m aware of), so the auto-advance feature is new to me. Generally auto-playing video is not ideal for some people with disabilities. (I’m assuming the UX of Auto Advance is overlapping with AutoPlay.). Here’s an explanation:

and

As accessibility concerns go, I wouldn’t say this is a blocker. But I’d prefer to see it as a user-controllable setting.

By the way, on Chrome a user can block auto-play with a setting:
How to Disable Autoplay Videos on Sites in Google Chrome (Updated).
so that might conflict with your intentions.

This says Chromium browsers don’t allow auto-play in most cases.

Note: muted auto-play / auto-advance would definitely introduce the possibility of some confusion for learners who have vision impairments.

Tangentially, I am interested in creating a new video xBlock to support Audio Description, multiple language tracks, ASL, etc., as well as VTT caption format and multiple storage back-ends. So if you’re also working on any of those features, let’s talk more!

Jeff
Accessibility Specialist for 2U / edX.org platform

Hi @Jeff_Witt, nice to see you here!

Not a fan of auto-advance personally (or even excessive use of video, but that is a conversation for another time :), but at least as implemented now, it’s indeed a user-settable toggle.

In any case, given it’s not actually working at the moment, hasn’t been for a while, and this is the first we hear of it… It’s probably indication that not a lot of people use the feature.

That would be awesome! We do hear about folks creating alternative video players in the community from time to time: for instance, Appsembler’s and RaccoonGang’s from a few years ago. Might be worth a look.

1h

Just to clarify, by user-controllable I mean controllable by the learner. I was reading the original question to mean that the behavior is currently controllable by the content host.

Yeah I have assumed that that particular xBlock is probably the best place to pick up from. The features I’d like to add are (mostly) currently in video.js and in AblePlayer.

Fair enough, we should get our terminology straight. :slight_smile: The content host enables the feature platform wide - it is off by default. Even if enabled in the platform, though, it is still off for all courses by default: the content author has to enable it for their course specifically. And finally, if their course has it enabled, the learner can toggle it on and off at will via a button in the player itself.

Hi Tramck,
I have seen this thread you have done a commendable job with video Xblock. I also wanted to something to this xblock. I need few advice from you you have tested video xblock fully. I am using HLS stream and not from AWS I am using 3rd party HLS stream.

  1. Can we implement multiple audio language choose option. So we don’t have to create multiple courses for each language each video will be available in multiple languages.
  2. Can user have right in player itself he can control player speed.
  3. Can user control video screen resolution of a video.
  4. If we use this xblock can we save HLS video stream in android mobile device.

can it is possible with current native (Edx main video player) Player.

Thanks in Advanced

@Parvin_Kumar

My strategy to build my own custom video xblock was to use video.js as the player library. The original reason my team needed a custom video xblock was to support vimeo videos instead of just youtube videos. Video.js doesn’t support vimeo out of the box but is extensible and allowed us to write a custom “Tech” class to support vimeo. Our custom video block and custom learning mfe are currently closed source, but if I am able to get the time I will take the lessons I learn while implementing auto-advance in these components and submit a PR to the appropriate open source repos.

I don’t believe this is supported by the native video player, but based on video.js documentation it seems like it might be possible to implement using video.js.

This is supported in the native video xblock and implementable using video.js.

I’m not sure whether or not the native video player supports this, but this relatively easy to implement in video.js.

Sorry, this is beyond my expertise. I don’t have any experience with HLS.

Hi @tramck ,
I am requesting if it is possible for you please open source this videojs xblock and remove your vimeo code integration from it. Why I am saying that we all can use that and customize the main videojs code according to our own needs. Videojs xblock code will be be saved I will try to add something into it and all credit goes to you please i am requesting you opensource this xblock in your github repo

Hi any update regarding code opensource