-
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
Hide the poster when play fires #1834
Conversation
Registering a play handler after loadstart means that another play listener could stop propagation and prevent the poster image from being hidden. Instead, handle the poster toggling in a play handler that is registered immediately on initialization so that the poster display logic more closely matches the standard.
Note the show poster flag should be set to |
Prefixing events before they were dispatched caused a number of handlers in video.js itself to fail. Instead, stopImmediatePropagation() on video events as they reach the ad plugin and perform the prefixing there. Add a content-resuming state so that events that are not strictly related to ad playback but distracting to downstream developers can be prefixed with 'content' easily as well. The poster image is not correctly removed from the example page without the fix in videojs/video.js#1834.
|
||
// hide the poster when the user hits play | ||
// https://html.spec.whatwg.org/multipage/embedded-content.html#dom-media-play | ||
if (!this.hasStarted()) { |
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.
The hasStarted method already handles this check, if you want to simplify this.
Makes sense to me. I think we originally put it in loadstart to avoid the extra logic each play event, but it's trivial if it's better to have it in the play handler. I like that we can point to spec here with the show poster flag, but hasStarted is used for other things too so I don't know if it helps to refer to hasStarted as the show poster flag specifically. Or at least I was thrown off by the test a little, because it refers to the poster and adds one, but the test doesn't actually need a poster. Otherwise this looks good to me. |
Yeah, I was nervous about equating hasStarted with the show-poster flag a bit too but I couldn't find anything else it was triggering that would interfere with poster behavior. I think it's worth considering an explicit show-poster flag in video.js so we can feel more confident the behavior is correct. |
hasStarted() already checks before updating the player element's class name so there is no need to check before calling it.
Prefixing events before they were dispatched caused a number of handlers in video.js itself to fail. Instead, stopImmediatePropagation() on video events as they reach the ad plugin and perform the prefixing there. Add a content-resuming state so that events that are not strictly related to ad playback but distracting to downstream developers can be prefixed with 'content' easily as well. The poster image is not correctly removed from the example page without the fix in videojs/video.js#1834.
Registering a play handler after loadstart means that another play listener could stop propagation and prevent the poster image from being hidden. Instead, handle the poster toggling in a play handler that is registered immediately on initialization so that the poster display logic more closely matches the standard.