I'm specifically trying to avoid a bad integration though, the API for <video> is quite clear for how to interact with a <video> element hosted on a page, as defined by the HTML5 spec.
This is the issue I have with this change, I'm following all the rules here and those rules apply to every video provider on the web for rendering video.
While I don't think it was purposeful, it certainly needs to be called out that crashing the entire page is certainly nonstandard behavior for a <video> element.
Fwiw, you can’t even trust the browsers to handle HTML5 media spec behavior the same way.
I just dealt with cross-browser issues in how setting currentTime on <audio> is handled because I needed a player to resume from a preset time.
On WebKit browsers, including desktop safari and all iOS browsers, you must wait for the ‘dataloadded’ or ‘canplay’ events to fire before trying to set currentTime.
On desktop Firefox / Chrome, you must set currentTime immediately prior to .play() or it won’t pick it up.
This is the issue I have with this change, I'm following all the rules here and those rules apply to every video provider on the web for rendering video.
While I don't think it was purposeful, it certainly needs to be called out that crashing the entire page is certainly nonstandard behavior for a <video> element.