add a compatibility layer for both config and setValue, to override any settings

Compare a variety of time trigger methods for more accurate skipping

• setTimeout + setInterval on finer times (same as extension)
• call function to check every timeupdate
• quick function on timeupdate to check against preset triggers

I use yewtu.be as an Invidious instance and would like to use this UserScript instead of a browser extension.

What changes would I need to make to the script (and which file would I install into my US manager)?

It seems like CORS wasn't configured properly so it's returning 403s, will see if the setting worked

Syntax error in script: sb.js userscript
await is only valid in async functions and the top level bodies of modules

The script just doesn't work, what should I do?

Expected Behavior
When using the version of the userscript with a configuration UI (sb-config-user.js), it should be possible to configure settings via the configuration page at https://mchangrh.github.io/sb.js/config.

Actual Behavior
The configuration UI does not appear at https://mchangrh.github.io/sb.js/config. Instead, it displays the message "SB.js not present", even though the latest version of the sb-config-user.js userscript is loaded.

Additional Notes
This issue appears to be due to two typos in the /src/gm_configpage.js file:

• Line 36 is accessing a non-existent property called url when it should be accessing URL.
• Line 4 does not correctly update the display style of the config element (compare lines 3 & 4)

Expected Behavior
The userscript version that has a configuration UI (sb-config-user.js) should be compatible with the same set of environments that the other versions are.

Actual Behavior
Userscript environments that don't support top-level await (e.g.: ViolentMonkey, Qutebrowser) will crash out of the sb-config-user.js userscript with the following error:

await is only valid in async function

Additional Notes
Top-level await is not a standard feature in userscript environments and implementations that do provide it are arguably going against the ECMA spec. I feel that it would be good for compatibility to do away with any dependencies on this behavior.