Fix audio waveform seeking behaviors

[sarayourfriend]

Fixes

Fixes #628 by @sarayourfriend
Fixes #623 by @sarayourfriend

Replaces #629 which had a coding error fixed in this PR anyway.

Description

Fixes keyboard navigation and both keyboard and mouse based seeking on the waveform.

Testing Instructions

Checkout the branch and run pnpm dev. Visit an audio result like http://localhost:8443/audio/632d0076-fdbd-4919-8b8f-b498ef246ee8 and test the keyboard and mouse waveform seeking on the result waveform. Also test this on the related audio.

Verify that you can:

1. Seek using the mouse
2. Seek multiple tracks and have them start playing at the correct position
3. Seek using the keyboard
4. Tab out of the waveform when using keyboard navigation

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• [N/A] I added or updated tests for the changes I made (if applicable).
• [N/A] I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[zackkrida]

I'm seeing a bug where if I let one track play, and then start another track, it begins at the seek point of the previous track instead of starting at the beginning.

[sarayourfriend]

@zackkrida Can you share steps to reproduce? I was seeing that behavior on main but this branch should fix it. Specifically this check here with the long comment is meant to address that problem:

https://github.com/WordPress/openverse-frontend/pull/633/files#diff-49554fdd9df51cf0c09140e074e486259b2fe8162c41407f3c8cabbd5767ba7dR144

[zackkrida]

@sarayourfriend If I click the play button of one track, let it play for x seconds, and then click the play button on another track, it will begin at the x seconds point.

[sarayourfriend]

That's really weird. I'm not able to reproduce that behavior at all, but maying I'm doing something different than what you're describing. Here's a video of me trying to reproduce it:

Gravacao.de.Tela.2022-01-18.as.15.12.28.mov

I did notice something happen with the first audio track where the waveform seemed to change size at some point. The playback continued smoothly and the timestamp stays correct, but it moves visibly backwards in the track, as though the track's length had been expanded somehow.

[zackkrida]

It's specific to Chrome! I tested in Firefox and Safari and saw the correct behavior.

[sarayourfriend]

Oh how strange! I'm not able to reproduce it on Chrome 97.0.4692.71 (on an Intel mac running macOS 11.6.2).

[sarayourfriend]

I do see one difference in Safari though and that is every time I play an audio track the current time is reset to 0 (which was the original behavior before this PR, but I have no idea why it's doing that on Safari and not Firefox or Chrome for me).

These are very strange differences!

[zackkrida]

Ah this is getting weird now-we'll probably need to have more folks check this out:

[sarayourfriend]

I'm wondering if it's a RAF timing issue for M1 macs or just the arm64 build of Chrome? We're on the same version otherwise.

[obulat]

I get a portion of the bug that Zack describes: It looks like the second track seek point starts at the point where the first one left off for a split second, but then it corrects itself. It starts playing from the beginning.

Oh, and I get that on both Firefox and Chrome.

[sarayourfriend]

Gosh these edge cases are so strange, I really can't pinpoint what is causing them other than a potential difference in how requestAnimationFrame is being timed. I almost wonder if we need to schedule a determined "final" pass the first time a new frame isn't requested? I'll try that out and see if it fixes it. But otherwise, I'm wondering if we could merge this PR as is for the sake of the release and then tackle these subtle bugs afterwards? Currently seeking doesn't work properly at all for keyboard users and behaves strangely for mouse users so at least this PR fixes that (even though it introduces some subtle, strange, and inconsistent bugs).

[zackkrida]

Suggested change

	window.audioEl.src = props.audio.url
	// Set the current time of the audio back to the seeked time
	// of the waveform/timeline. In the future we might change
	// this to reset the audio back to 0 anytime another audio
	// is played but for now this is simpler and requires less
	// cross-instance communication.
	window.audioEl.currentTime = currentTime.value
	// Set the current time of the audio back to the seeked time
	// of the waveform/timeline. In the future we might change
	// this to reset the audio back to 0 anytime another audio
	// is played but for now this is simpler and requires less
	// cross-instance communication.
	window.audioEl.currentTime = currentTime.value
	window.audioEl.src = props.audio.url

@sarayourfriend this one weird trick fixes all of the problems for me! I haven't tested this + removing your other attempts to fix browser bugs but I will do so now.

Edit: Actually, this prevents the current track from being seeked prior to start.

[sarayourfriend]

@obulat, just FYI @zackkrida and I ended up pairing on this for a little while to try to resolve the bugs and decided that it might require some significant refactors.

@zackkrida how do you feel about merging this PR as is and then trying those refactors in a follow up? Trying to be conscious of the fact that this PR does fix some fundamentally broken flows, even if it's not perfect. The refactors we discussed might fix everything, but so far they've been really difficult to work out how to get right and I'm in a worse spot than this PR is at the moment.