-
Notifications
You must be signed in to change notification settings - Fork 7.4k
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: rely on browser or tech to handle autoplay #4582
Conversation
@videojs/core-committers any thoughts on the removal of those two In the Seems like the html5 one was added 4 years ago for iOS 6 support: 7d67abd Seems like removing these pieces could potentially cause older browsers to misbehave. |
Could there be people relying on this behavior when switching videos? If so we might want this to be a major version change, unless it's breaking something now. |
It's theoretically possible but I find it unlikely. I think the reason the code was there was for flash but also because we did a bad job at setting attributes/properties on the video element, which was recently fixed in #4562. |
I think "fix" is appropriate here. If our goal is emulating/mirroring the standard behavior, this gets us closer to that in a way it wasn't before. For Yeah, I think that can probably be safely removed, based on my assumptions about browser usage. But @heff's concerns are valid as well. |
Although "fix" is appropriate for this project, it does mean a change to the behavior of the underlying tech/player which is concerning and I think would push this towards a "feat" so users have the ability to test and update their integrations. I agree with updating
|
Removing Also, I tested this change with videojs-youtube and it autoplays. Looking at a selection of other techs from the wiki. |
I tested it with a few others but either couldn't get them to work at all or they don't autoplay regardless of this change (like the soundcloud tech). |
An advantage of using |
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.
I feel comfortable with this as fix.
I'd also be interested to explore how we can use the play()
promise like @mister-ben suggested, but that can be separate from this.
Description
When setting the source, we were calling
play
ifautoplay
was set. We shouldn't do that and instead we should rely on the browser or tech (like Flash) to handle it properly.I'm unsure whether this should be a
fix
or afeat
, thoughts?There are two more places that we should consider removing but they are probably OK because they're specific/bug fixes rather than general "if autoplay, call play" kind of deals.
There's one in
enterFullscreen
on the html5 tech, which should only be called on iOS devices.video.js/src/js/tech/html5.js
Lines 548 to 557 in fe63992
In the player, in
handleTechReady_
, there's another call toplay
, which is a fix for older chrome and older safari. This one seems more of a candidate for removal than the html5 one above.video.js/src/js/player.js
Lines 1068 to 1079 in fe63992
Requirements Checklist