vime icon indicating copy to clipboard operation
vime copied to clipboard

TypeError: Cannot read properties of undefined (reading 'trim')

Open nick4414 opened this issue 1 year ago • 10 comments

Hi, since the 10.01.2024 all our users get the bug:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'trim') at Object.buildAbsoluteURL (url-toolkit.js:21:33) at e.loadSource (hls.ts:401:39) at HLS. (video-player~user-account.js?id=fd885bb62350cccedb83:82493:65) at Generator.next () at video-player~user-account.js?id=fd885bb62350cccedb83:82360:67 at new Promise () at push../node_modules/@vime/core/dist/custom-elements/index.js.__awaiter$f (video-player~user-account.js?id=fd885bb62350cccedb83:82346:10) at HLS.onSrcChange (video-player~user-account.js?id=fd885bb62350cccedb83:82490:12) at t. (video-player~user-account.js?id=fd885bb62350cccedb83:82413:16) at o.emit (index.js:203:33)

when using the HLS Player. I didn't change the code for months. There was a Chrome, Edge, Safari Update on the 10.01.24 and that's when the errors started. Could it be a problem on your end ?

EDIT: Your HLS demo has the same issue: https://vimejs.com/demo

nick4414 avatar Jan 11 '24 12:01 nick4414

Same

lucasmgsilva avatar Jan 11 '24 12:01 lucasmgsilva

Looks related to hls.js v1.5.x released 2 days ago. https://github.com/video-dev/hls.js/releases/tag/v1.5.0

I added version="1.4.14" as workaround in the Hls props to mitigate this issue. Been going through the hls.js release notes and so far have not found any clue why it is breaking.

debug logs:

[log] > Debug logs enabled for "Hls instance" in hls.js version 1.5.0
hls.ts:380 [log] > attachMedia
buffer-controller.ts:192 [log] > [buffer-controller] created media source: MediaSource
index.js:1273 [error] > Media element src was set while attaching MediaSource (blob:http://localhost:3001/b3797da8-daaf-462d-8b61-f0ef5340d581 > undefined)
buffer-controller.ts:979 [log] > [buffer-controller] Media source opened
hls.ts:442 [log] > stopLoad

ashveen avatar Jan 11 '24 13:01 ashveen

Hi, since the 10.01.2024 all our users get the bug:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'trim') at Object.buildAbsoluteURL (url-toolkit.js:21:33) at e.loadSource (hls.ts:401:39) at HLS. (video-player~user-account.js?id=fd885bb62350cccedb83:82493:65) at Generator.next () at video-player~user-account.js?id=fd885bb62350cccedb83:82360:67 at new Promise () at push../node_modules/@vime/core/dist/custom-elements/index.js.__awaiter$f (video-player~user-account.js?id=fd885bb62350cccedb83:82346:10) at HLS.onSrcChange (video-player~user-account.js?id=fd885bb62350cccedb83:82490:12) at t. (video-player~user-account.js?id=fd885bb62350cccedb83:82413:16) at o.emit (index.js:203:33)

when using the HLS Player. I didn't change the code for months. There was a Chrome, Edge, Safari Update on the 10.01.24 and that's when the errors started. Could it be a problem on your end ?

EDIT: Your HLS demo has the same issue: https://vimejs.com/demo

did you by any chance get a workaround on this? especially on hls videos?

BBR-Agency avatar Jan 13 '24 09:01 BBR-Agency

A workaround is (like @ashveen mentioned):

<template>
  <Player controls>
    <Hls :config="hlsConfig" version="1.4.14" poster="/media/poster.png">
      <source data-src="/media/index.m3u8" type="application/x-mpegURL" />
    </Hls>
    <!-- ... -->
  </Player>
</template>

Just use the older version 1.4.14 of the HLS package, not the latest one.

nick4414 avatar Jan 13 '24 12:01 nick4414

Thanks for the quick workaround @ashveen

sheerazabbas avatar Jan 15 '24 16:01 sheerazabbas

Hi, since the 10.01.2024 all our users get the bug:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'trim') at Object.buildAbsoluteURL (url-toolkit.js:21:33) at e.loadSource (hls.ts:401:39) at HLS. (video-player~user-account.js?id=fd885bb62350cccedb83:82493:65) at Generator.next () at video-player~user-account.js?id=fd885bb62350cccedb83:82360:67 at new Promise () at push../node_modules/@vime/core/dist/custom-elements/index.js.__awaiter$f (video-player~user-account.js?id=fd885bb62350cccedb83:82346:10) at HLS.onSrcChange (video-player~user-account.js?id=fd885bb62350cccedb83:82490:12) at t. (video-player~user-account.js?id=fd885bb62350cccedb83:82413:16) at o.emit (index.js:203:33)

when using the HLS Player. I didn't change the code for months. There was a Chrome, Edge, Safari Update on the 10.01.24 and that's when the errors started. Could it be a problem on your end ?

EDIT: Your HLS demo has the same issue: https://vimejs.com/demo

Yeah, that seems to be a bad implementation in @vime/vue for using dependencies with cdn @mihar-22, I know this is not actually your package fault but in case if you use all other dependencies with their cdn. they will get updated from time to time even with bugs that what users currently face even they don't have updated their package. As you guys are going toward #Vidtack package. Please keep in mind that you should use dependencies as module part of your package not as cdn So, your package could be stable till every update you launch. Thanks

Tayyab-Abbas avatar Jan 16 '24 09:01 Tayyab-Abbas

Downgrading HLS to 1.4.14 does not fix the issue on Safari. On desktop Safari half the times it works other half not. On iOS Safari I get the same error every time.

sven-ra avatar Jun 11 '24 09:06 sven-ra

image

On Safari this seems to be related to how sources are used. In Chrome the actual m3u8 URL with type application/x-mpegURL is used but in Safari an object URL is used with type video/mp4. The code that's failing is looking for either a source ending in m3u8 or a source with application/x-mpegURL type and it isn't finding either of them. I'm trying to figure out whether this is an HLS.js problem or a Vime problem since the HLS.js demo works fine on their website in Safari.

Here's how it looks in Chrome for comparison:

image

zshall avatar Jul 22 '24 12:07 zshall

I've turned on debug logs in HLS.js in Safari and collected this one: [error] >"Media element src was set while attaching MediaSource (blob:http://localhost:5173/7f520dde-4d88-4b5d-bfc8-9c340d5bcc3a > undefined)"

Tracking it down I've noticed HLS.js sets an object URL and changes the source element. https://github.com/video-dev/hls.js/blob/c21f4bf863968283ab26afe460c070d05166a4f9/src/controller/buffer-controller.ts#L241

This fires the emptied event on the video element and produces that logging error. Now the src is undefined, which triggers onSrcChange in Vime it appears. https://github.com/vime-js/vime/blob/c1f311950c52b5c49329873a6bb9739f3727223f/packages/core/src/components/providers/hls/hls.tsx#L239

image

This listener is called with the m3u8 URL when the page loads:

image

And then again after the element was replaced with undefined.

This appears to be happening right here: https://github.com/vime-js/vime/blob/c1f311950c52b5c49329873a6bb9739f3727223f/packages/core/src/components/providers/hls/hls.tsx#L128 the onSrcChanged event fires when get src() returns something else. It's returning nothing since it only looks for m3u8 or the mpeg content type. Either way it doesn't find it and the loadSource function is called again with undefined.

Investigating fixes; I'm not familiar with Vime's build pipeline but it seems like this could be the hotspot to focus on.

zshall avatar Jul 23 '24 01:07 zshall

I've put together a change that seems to have fixed the problem; a cache has been added to the HLS source URL that will return if it ends up getting set. That way if HLS.js sets the URL to an object URL it won't try to load the new blob: URL or undefined and will return the old URL, which prevents the bug.

zshall avatar Jul 23 '24 03:07 zshall