This repository has been archived by the owner on Feb 22, 2023. It is now read-only.
Audio waveform progress bar extends beyond the end of the waveform body #692
Assignees
Labels
🕹 aspect: interface
Concerns end-users' experience with the software
bug
Something isn't working
🛠 goal: fix
Bug fix
good first issue
New-contributor friendly
help wanted
Open to participation from the community
🟨 priority: medium
Not blocking but should be addressed soon
🚦 status: awaiting triage
Has not been triaged & therefore, not ready for work
Comments
sarayourfriend
added
good first issue
|
👋 |
demophoon
added a commit
to demophoon/openverse-frontend
that referenced
this issue
Feb 6, 2022
When an audio file is played and the duration from the passed properties does not match the duration of the actual audio file, e.g. the duration was rounded, the progress bar drifts outside of the total width of the VWaveform dimensions. On smaller width screens or larger tracks it is less noticeable but when the audio track is small and the screen width is large that percentage adds up to 10s or more of pixels which is where the bug crops up. This commit fixes this issue by by using the audio context's duration parameter and falling back to less specific sources for duration.
7 tasks
demophoon
added a commit
to demophoon/openverse-frontend
that referenced
this issue
Feb 7, 2022
When an audio file is played and the duration from the passed properties does not match the duration of the actual audio file, e.g. the duration was rounded, the progress bar drifts outside of the total width of the VWaveform dimensions. On smaller width screens or larger tracks it is less noticeable but when the audio track is small and the screen width is large that percentage adds up to 10s or more of pixels which is where the bug crops up. This commit fixes this issue by by using the audio context's duration parameter and falling back to less specific sources for duration.
7 tasks
demophoon
added a commit
to demophoon/openverse-frontend
that referenced
this issue
Feb 18, 2022
Before this commit the duration would be set based on the audio context state as the page was loaded. Since the audio file is never loaded by the time we check for the duration of the audio object, it is always null thus defaulting to the metadata for audio duration always. This commit adds a `durationchange` listener while initializing the audio object and sets the duration in a new `audioDuration` property which the computed `duration` property watches.
demophoon
added a commit
to demophoon/openverse-frontend
that referenced
this issue
Feb 18, 2022
Before this commit the duration would be set based on the audio context state as the page was loaded. Since the audio file is never loaded by the time we check for the duration of the audio object, it is always null thus defaulting to the metadata for audio duration always. This commit adds a `durationchange` listener while initializing the audio object and sets the duration in a new `audioDuration` property which the computed `duration` property watches.
demophoon
added a commit
to demophoon/openverse-frontend
that referenced
this issue
Feb 18, 2022
Before this commit the duration would be set based on the audio context state as the page was loaded. Since the audio file is never loaded by the time we check for the duration of the audio object, it is always null thus defaulting to the metadata for audio duration always. This commit adds a `durationchange` listener while initializing the audio object and sets the duration in a new `audioDuration` property which the computed `duration` property watches.
sarayourfriend
pushed a commit
that referenced
this issue
Feb 19, 2022
* (#692) Fix duration mismatch between audio and metadata When an audio file is played and the duration from the passed properties does not match the duration of the actual audio file, e.g. the duration was rounded, the progress bar drifts outside of the total width of the VWaveform dimensions. On smaller width screens or larger tracks it is less noticeable but when the audio track is small and the screen width is large that percentage adds up to 10s or more of pixels which is where the bug crops up. This commit fixes this issue by by using the audio context's duration parameter and falling back to less specific sources for duration. * #692) Set duration after audio is loaded Before this commit the duration would be set based on the audio context state as the page was loaded. Since the audio file is never loaded by the time we check for the duration of the audio object, it is always null thus defaulting to the metadata for audio duration always. This commit adds a `durationchange` listener while initializing the audio object and sets the duration in a new `audioDuration` property which the computed `duration` property watches.
7 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
When playing an audio file all the way through to the end, the progress bar will extend beyond the end of the waveform body.
I'm not sure what causes this, but it seeems like it would just be a small math issue or more likely we're ignoring something critical when pulling the waveform dimensions from
clientWidth.Reproduction
Expectation
The progress bar should end exactly at the end of the waveform body.
Screenshots
The text was updated successfully, but these errors were encountered: