fix: try again on volume feature detection on iOS #7514
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On latest iOS, we are seeing times when the volume feature detection is showing that we are able to change the volume, though, that is not the case. Instead, on iOS, when we detect that we can control the volume, we set a short timer to retest and reset the the featuresVolumeControl property. Fixes #7040
Codecov Report
@@ Coverage Diff @@
## main #7514 +/- ##
==========================================
- Coverage 79.84% 79.83% -0.02%
==========================================
Files 116 116
Lines 7309 7313 +4
Branches 1764 1765 +1
==========================================
+ Hits 5836 5838 +2
- Misses 1473 1475 +2
Continue to review full report at Codecov.
|
gesinger
reviewed
Nov 17, 2021
src/js/tech/html5.js
Outdated
Comment on lines
1038
to
1041
| // on latest iOS, there are cases where we read the volume as changed. | ||
| // In those cases, we should add a timeout and check again later. | ||
| // Since features doesn't currently work asynchronously, | ||
| // we then have to manually set the new value. |
There was a problem hiding this comment.
I wanted to make sure I understand fully what's happening, so I tried updating the comment a bit with my understanding. Let me know if there's anything off here, or if it's better off the way it was.
Suggested change
| // on latest iOS, there are cases where we read the volume as changed. | |
| // In those cases, we should add a timeout and check again later. | |
| // Since features doesn't currently work asynchronously, | |
| // we then have to manually set the new value. | |
| // With the introduction of iOS 15, there are cases where the volume is read as | |
| // changed but it reverts back to its original state at the start of the next tick. To | |
| // determine whether volume can be controlled on iOS, a timeout is set and the | |
| // volume is checked asynchronously. | |
| // Since `features` doesn't currently work asynchronously, the value is manually set. |
There was a problem hiding this comment.
Updated it manually to adjust positioning
gesinger
approved these changes
Nov 17, 2021
gkatsev
added a commit
that referenced
this pull request
Dec 1, 2021
This is a follow-up to #7514. But turns out, that we still had a timing issue around when we were doing the check and when the volume control was created. Instead, we should make `featuresVolumeControl` not be a lazy property, so, that we do that check as early as possible. Also, we should default this property to `false` in this case, so, that we assume we can't until we confirm we can. Additionally, added a null check for Html5, to be extra defensive since the timeout isn't to a player.
gkatsev
added a commit
that referenced
this pull request
Dec 1, 2021
This is a follow-up to #7514. But turns out, that we still had a timing issue around when we were doing the check and when the volume control was created. Instead, we should make `featuresVolumeControl` not be a lazy property, so, that we do that check as early as possible. Also, we should default this property to `false` in this case, so, that we assume we can't until we confirm we can. Additionally, added a null check for Html5, to be extra defensive since the timeout isn't tied to a player.
edirub
pushed a commit
to edirub/video.js
that referenced
this pull request
Jun 8, 2023
On latest iOS, we are seeing times when the volume feature detection is showing that we are able to change the volume, though, that is not the case. Instead, on iOS, when we detect that we can control the volume, we set a short timer to retest and reset the featuresVolumeControl property. Fixes videojs#7040
edirub
pushed a commit
to edirub/video.js
that referenced
this pull request
Jun 8, 2023
This is a follow-up to videojs#7514. But turns out, that we still had a timing issue around when we were doing the check and when the volume control was created. Instead, we should make `featuresVolumeControl` not be a lazy property, so, that we do that check as early as possible. Also, we should default this property to `false` in this case, so, that we assume we can't until we confirm we can. Additionally, added a null check for Html5, to be extra defensive since the timeout isn't tied to a player.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On latest iOS, we are seeing times when the volume feature detection is
showing that we are able to change the volume, though, that is not the
case. Instead, on iOS, when we detect that we can control the volume, we
set a short timer to retest and reset the featuresVolumeControl property.
Fixes #7040