iframe API startAt bug

[jaredp_]

Hello!

I was working with the Spotify iframe API found here:

https://open.spotify.com/embed/iframe-api/v1

and noticed a bug related to this.options.startAt found in this script:
https://embed-cdn.spotifycdn.com/_next/static/iframe_api.92ca45a15d3476e3ab9a.js 

the bug is found inside the function loadUri:

this.loadUri = (uriString, preferVideo = false, timestampInSeconds = 0)

specifically this block:

if (this.options.startAt || timestampInSeconds) {
  const startAt = timestampInSeconds !== null && timestampInSeconds !== void 0 
    ? timestampInSeconds 
    : parseInt((_a = this.options.startAt) !== null && _a !== void 0 ? _a : '0', 10);
  
  if (!isNaN(startAt)) {
    embedURL.searchParams.append('t', startAt.toString());
  }
}

the bug is that this.options.startAt will never be used since timestampInSeconds defaults to 0.

to fix it, I believe all that needs to be added is && timestampInSeconds !== 0 so we fallback to this.options.startAt if it is 0:

if (this.options.startAt || timestampInSeconds) {
  const startAt = timestampInSeconds !== null && timestampInSeconds !== void 0 && timestampInSeconds !== 0 
    ? timestampInSeconds 
    : parseInt((_a = this.options.startAt) !== null && _a !== void 0 ? _a : '0', 10);
  
  if (!isNaN(startAt)) {
    embedURL.searchParams.append('t', startAt.toString());
  }
}

P.S: I'm not really sure why timestampInSeconds exists since the loadUri function is only called with 2 arguments everytime (uri and preferVideo) 

not sure where the correct place to post this was, hopefully this was the place!

[trevorflan]

When I was using the iFrame API, I had a similar use case. I saw that there were some stubs for startAt, but they never did anything. I ended up hacking together a solution that just called seek() until the page finished loading, but this would have been much cleaner. +1

[stellaw1]

+2!