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)[edx-platform/courseware-chromeless.html at master · openedx/edx-platform · GitHub]. 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.