SponsorBlock
SponsorBlock copied to clipboard
[feature request] YouTube starts playing before SponsorBlock has a chance to skip (stop autoplay workaround).
a race between YouTube autoplay and SponsorBlock (usually autoplay wins 😥)
example
https://user-images.githubusercontent.com/415238/156748325-fe757277-e1d3-4f8e-bf40-b91ea7b367c7.mp4
possible workaround (stopping autoplay)
-
Firefox and Edge can control autoplay using the UI.
until a click/keypress calls to.play
will be rejected. -
Chromium has no autoplay control in the UI, but Windows builds would support a global policy (registry)
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Policies\Chromium] ;"AutoplayAllowed"=dword:00000001 "AutoplayAllowed"=dword:00000000
see
policy_templates.zip
at
https://github.com/Hibbiki/chromium-win64/releases/tag/v102.0.5005.63-r992738it would effect every website, every chromium browser, and every user on the machine.
-
a web-extension can inject
feature-policy
http header withautoplay 'none';
withdeclarativeNetRequest
permission.
https://html.spec.whatwg.org/multipage/infrastructure.html#autoplay-feature
it isn't well supported yet. -
custom autoplay polyfill. restrict
HTMLVideoElement.prototype.play
by default, and re-allow based on user interaction.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/play
Simple to implement via playbackRate if all you wanted was a delay until the times are loaded.
Probably worth checking why a video can load faster then sponsor times :) Adding a delay would make the performance worse.
The kubernetes server deployment fetches stuff a lot faster, so this might be less of an issue once I'm done migrating. Right now, requests sometimes take up to a second at peak time, which causes this effect
Right now it is based on the URL, which does give it a lot of time before the DOM changes
Instead of pausing the video until we get the response from the API call, can we instead preload and cache the next videos sponsor details if AutoPlay is on and < 5 seconds is left in the video? I know this wouldn't solve all the issues of the response coming after the video starts, but it would at least solve the autoplay issue.
the response time is not the cause,
it is because there are two async actions trying to happen in the same time,
playing video and api response,
microsecond delay of the api call will make the play go first,
that is not a good design,
the play should always be in-sync, I.E. after, the api call,
in worst case, delay to amount of time pre-defined until the api call should be canceled and declared as not-available (max 5 seconds limit),
instead of letting the network implementation throw timeout.
several ways exists to cache existing, previously fetched data,
from plain cache headers with stale notifications, to local-storage keeping previous calls as a fallback to timeout.
all those were suggested before and rejected.
this is why I've suggested to add autoplay stopping as a generic solution.
that said it doesn't seems to be any clear solution so I'm closing it for now,
users of edge or firefox can define youtube.com to not have auto-play allowed,
and it is good enough solution.