[feature request] YouTube starts playing before SponsorBlock has a chance to skip (stop autoplay workaround).

[eladkarako]

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)

1. Firefox and Edge can control autoplay using the UI.
   until a click/keypress calls to .play will be rejected.

2. 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-r992738

   it would effect every website, every chromium browser, and every user on the machine.

3. a web-extension can inject feature-policy http header with autoplay 'none'; with declarativeNetRequest permission.
   https://html.spec.whatwg.org/multipage/infrastructure.html#autoplay-feature
   it isn't well supported yet.

4. 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

[NDevTK]

Simple to implement via playbackRate if all you wanted was a delay until the times are loaded.

[NDevTK]

Probably worth checking why a video can load faster then sponsor times :) Adding a delay would make the performance worse.

[ajayyy]

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

[ajayyy]

Right now it is based on the URL, which does give it a lot of time before the DOM changes

[ghost]

An extension might help?

[SebTota]

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.

[eladkarako]

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.