-
Notifications
You must be signed in to change notification settings - Fork 7.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: progress bar sometimes is not filled on 100% #8633
fix: progress bar sometimes is not filled on 100% #8633
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #8633 +/- ##
==========================================
- Coverage 83.43% 82.71% -0.72%
==========================================
Files 113 113
Lines 7636 7638 +2
Branches 1835 1835
==========================================
- Hits 6371 6318 -53
- Misses 1265 1320 +55 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable.
Oh my, I encountered this issue today as well. My app is behaving very strangely, with short videos randomly getting stuck on a specific frame. But I found that it has not been merged in yet, when can the new version be released? |
The test added here is susceptible to timing out on Safari if Safari is in the background, but passes consistently when in the foreground. |
… instead of first (#8799) ## Description The current implementation of `requestNamedAnimationFrame` prevents multiple updates on a frame but by disregarding all but the first request per frame. This throttling behaviour is apparent when playing a very short video - if a `timeupdate` occurs just before the `ended` event, the progress bar position on the `timeupdate` is set at say 98% and 100% from the `ended` is discarded. Although #8633 removed the throttle from the `ended` handler itself, the throttle and non-throttled update can still both execute between frames. ## Specific Changes proposed Changes the implementation to apply only the last callback instead. If any exist they will be cancelled. There will still be only one update, but now it's the last. Updates tests to reflect the changed behaviour. Fixes #8782 ## Requirements Checklist - [x] Feature implemented / Bug fixed - [ ] If necessary, more likely in a feature request than a bug fix - [x] Change has been verified in an actual browser (Chrome, Firefox, IE) - [x] Unit Tests updated or fixed - [ ] Docs/guides updated - [ ] Example created ([starter template on JSBin](https://codepen.io/gkatsev/pen/GwZegv?editors=1000#0)) - [x] Has no DOM changes which impact accessiblilty or trigger warnings (e.g. Chrome issues tab) - [x] Has no changes to JSDoc which cause `npm run docs:api` to error - [ ] Reviewed by Two Core Contributors
Description
At the end of the video progress bar not in the end.
This is random behavior and it is best visible on short videos.
Specific Changes proposed
The player shouldn't throttle 'ended' event.
Requirements Checklist