yeatmanlab / roar-mep

Rapid Online Assessment of Reading -- Multiple Element Processing
Other
1 stars 3 forks source link

Videos not playing on iOS #18

Open richford opened 1 year ago

richford commented 1 year ago

The instructional videos do not play on iOS, on either Safari or Chrome.

Shared keyword arguments for all of the video trials are specified here: https://github.com/yeatmanlab/roar-mep/blob/29dec7a74480333e937eccd5ba71bdb2fdaf99b6/src/videos.js#L6

The site is live at https://roar-mep.web.app/ and any PR onto the main branch will also create a temporary demo website with which to test on iOS. For me on iOS, the first video ends prematurely. If I play through, then the second video hangs indefinitely without starting.

richford commented 1 year ago

PR #19 did indeed fix the autoplay of the first video. Unfortunately it does not resolve the issue with the second video. So we're definitely making progress but the issue persists.

@celsoyh, you asked

Not sure if there is any other issue, saw that there is a second video on it that is not playing but couldn't find it. When does it need to be played?

The second video play after the practice block. So one has to watch the first instructional video, and then play through eight practice stimuli by clicking on the buttons at the bottom when they appear. After the eighth input, another video is supposed to play but the video hangs.

I'm going to reopen this issue for now until we can resolve the remaining videos.

richford commented 1 year ago

@celsoyh , thanks again for your rapid response and on the progress so far in getting the first video to autoplay.

By the way, you mentioned in #19 that you inspected which events were firing and when. Would you mind sharing what tools you used to inspect this? I've been using https://inspect.dev/ with limited success to get a Chrome DevTools-like experience on iOS. But if you have a better approach, I would love to learn about it.

celsoyh commented 1 year ago

@richford no worries!

I'm using the XCode's Simulator to test against iOS Devices. When I use it, I can open the DevTools in my Safari. So I can have the power of inspecting the iOS device browser like I'm on a MacOS/Windows.

But the approach I used to investigate this bug was checking the code and see what could possibly cause the video not to play. So I got into the fullscreen function.

I did another test to identify the second video issue, and appears to be a very known iOS bug. The user needs to have an interaction to play the video, but I think that you already know about it. There are other solutions for this, but since this video was appearing right after the jsPsychAudioKeyboardResponse type assessment, I couldn't proceed to debug it because of the available time. Also, I checked the open issues on the jsPsych repo, and there were a few people with the same problem. Not sure if that was solved or not. Maybe using the video-button-response could be a quick fix.

qbunt commented 1 year ago

👋 @richford I'm the lead on Celso's team. Want to keep this moving, but there will likely be a delay in contributions to the codebase.

You're likely aware of the limitations, but I would review iOS policy for video playback. I strongly suspect that implementation details in the framework is what's biting you (Chrome has similar policy now, put in place to combat annoying ads).

Safari will log playback stoppage in the console. If there's any difference in that video (like there's an audio track), that's likely triggering intervention.

Would you mind sharing what tools you used to inspect this?

This is the approach we use , stock Mac/iOS tooling will help debug on-device, you can breakpoint in the Safari dev tooling

qbunt commented 1 year ago

@richford I've debugged your live site on iPad and have more info and a potential fix suggestion.

I can confirm that this is what you're seeing in iOS. autoplay is set, but because you have a button interaction while the video element is in the DOM, iOS proceeds with autoplay as you're clearly interacting with the page, so no block occurs.

Video element #2 is a brand new video tag is injected into the DOM, again with autoplay present, audio attached, and Safari (and all other browsers) intervene because that's against policy. More of this here.

My suggestion would be to change the UX. Either keep the same video element in the page at all times, OR to put a button element layered on top (similar to your star) or adjacent to video 2 to prove to Safari that the user has interacted with the page. Other JSPsych users have the same issue and provide some solutions in that discussion.

I will also add that muting the audio when the video is mounted into the DOM will not work, neither will programmatically clicking the 'play' button on the user's behalf, Safari has mitigations for both