Media player not working on this exhibit page: https://exhibits.stanford.edu/Kahn/feature/design-soul-body/

caaster commented 9 months ago

Submitted by Josh Schneider as exhibits feedback: "Per conversation with Andrew Berger, I'm filing exhibits feedback as the embedded video and audio viewers of SDR content on this page are not playing properly on this page. We used Chrome and Safari browser on Macs."

Individually, each of the items plays ok when you go to the individual purls. It’s when they’re stacked together on that specific page that the problems appear.

It appears that the iframe widget may not be working correctly on https://exhibits.stanford.edu/Kahn/feature/design-soul-body/ ?

caaster commented 9 months ago

FYI re importance of fixing this...the donor's son, Ira Kahn, has reached out to Josh Schneider asking for this to be fixed.

hudajkhan commented 9 months ago

@corylown , @marlo-longley, @taylor-steve and I looked through this issue to understand what the problems might be.

Between the four of us, for some of us the videos did not load in Firefox while they did load for others. Chrome did not always work and Safari didn't load all the videos. (Please feel free to comment/add if I missed anything).

Cory created a test exhibit on staging, and we added the same iframes for the videos and audios in the same order as on productions. The videos all loaded and the audios as well in Firefox and Chrome.
We then tried to see if we could recreate the error and compared the iframe code against that in production. We noticed there were attributes on the iframe that we had not used. We added "allowclipboard" and some of the videos started breaking.
We then went to the production site and removed "allowclipboard" on the first iframe. The videos now load in Firefox and Chrome.
We also saw these attributes are deprecated: frameborder, marginwidth, marginheight and scrolling. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe.
We also tried adding the "sandbox" attribute. That seemed to break the video functionality even where it had been working for us.
Marlo created a second page to set up minimal iframe content, i.e. iframes with no attributes beyond "src". This seemed to improve the situation in Safari but may not have fixed it entirely.

corylown commented 8 months ago

I can duplicate this issue on a plain html page outside of exhibits, so I think this is not specific to spotlight/exhibits. I suspect the problem may be related to an interaction between the dynamic embed content of the iframe and browser caching behavior. If the page is not cached then all the videos/audio seem to load fine. On subsequent page loads some players do not load, seemingly at random. A hard refresh of the page allows all the players to load most of the time. I wonder if some event is not firing if the iframe content is loaded from the browser cache. The other factor seems to be the number of iframes on the page. The problem starts to show up when there are between 3 and 5 iframe embeds on the page.

Here's the basic html testing page I used:

<html>
<head>
</head>
<body>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/qj391vf7548" height="400px" width="100%" allow="fullscreen"></iframe>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/xn451vy1602" height="400px" width="100%" allow="fullscreen"></iframe>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/yw026rg3724" height="400px" width="100%" allow="fullscreen"></iframe>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/nv680dn0560" height="400px" width="100%" allow="fullscreen"></iframe>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/zn794db1634" height="400px" width="100%" allow="fullscreen"></iframe>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/gw944fr8179" height="400px" width="100%" allow="fullscreen"></iframe>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/ns334jz9908" height="400px" width="100%" allow="fullscreen"></iframe>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/fk776pw5405" height="400px" width="100%" allow="fullscreen"></iframe>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/wz674vy5683" height="400px" width="100%" allow="fullscreen"></iframe>
<iframe src="https://embed.stanford.edu/iframe?url=https://purl.stanford.edu/hs145fq1412" height="400px" width="100%" allow="fullscreen"></iframe>
</body>
</html>

taylor-steve commented 8 months ago

I don't know how relevant this is, but I spent some time looking at this earlier when I was trying to understand Stimulus.

It seems when the player doesn't load for a given player I see this timeline:

media_tag controller connects
CustomEvent auth-success is dispatched
media_player_controller connects

If you manually dispatch auth-success (to the iframe window) the player will load successfully.

When the player does load, I see this timeline:

media_tag controller connects
media_player_controller connects
CustomEvent auth-success is dispatched

I'm not knowledgeable enough yet to tell if this is getting further to the cause or if I'm just more verbosely stating the symptoms...

hudajkhan commented 8 months ago

Thanks @corylown and @taylor-steve ! I do think there's an interplay between authorization and the media player, but I'm not sure about the specifics. (One does have to work/be recognized as working for the other to load). Worthwhile to follow up.

taylor-steve commented 8 months ago

I tried a quick and dirty local override to test my assumption.

Stored the authResponse status in the media_tag controller's validateMedia:

afterValidate(result, completeCallback) {
    if (result.authResponse.status === 'success') {
      // Store the authResponse for media_player to check in case it isn't initialized before the event is dispatched
      window.authResponseStatus = result.authResponse.status

Then in the media_player controller I added a connect method that initializes the player if the status was already recorded and successful (which also means the even was already dispatched).

connect() {
    if (window.authResponseStatus === 'success') {
      this.initializeVideoJSPlayer();
    }
}

With this setup, Cory's test html loads all videos 100% of the time on Safari for me. I feel confident we're on the right track with the event timing being the issue, but I'm not confident enough with the embed codebase to say that my naive solution is a good idea... Obviously how I have it only works if there's one embed per window. Still feels like there should be a better way to handle this.

jcoyne commented 8 months ago

Has anyone tried scoping the event dispatch to the player and not the whole window?

taylor-steve commented 8 months ago

Yes, I have since tried rescoping the events. It is definitely needed, for example druid qj391vf7548 has two videos with two separate auth urls and success on one will initialize both. I'll write that up as another issue.

I think what is going on here is not related to browser specifics (although they play a part) or multiple embeds. I think this is strictly a binding timing issue, especially on slow connections. If I throttle my browser down to ~5000-7500 Kbps, auth-success is almost always dispatched prior to the initializeVideoJSPlayer binding being added, so we see this fail to init behavior. This happens on any sul-embed for audio/video, single or multiple embed, all browsers that I've tried. I've seen this happen consistently on my phone on prod, especially when on my slow 4g connection.

Here are some logs showing for a single embed. Failed is throttled, the success log is still throttled but at a slightly faster speed. These situations have been very repeatable and consistent on my end.

Failed Load.log Successful Load.log

I've got a low effort low risk (I think) draft PR (https://github.com/sul-dlss/sul-embed/pull/2095) that fixes this for me.

sul-dlss / exhibits

Media player not working on this exhibit page: https://exhibits.stanford.edu/Kahn/feature/design-soul-body/ #2385