Greasy Fork

Add close button to Warning (or there's some videos where it isn't working in Chrome)

I'm using Chrome Dev 63.0.3213.3 on Windows 7 SP1 with updates up through August.

I get the "not working" error on Dice Funk podcast videos, e.g. https://www.youtube.com/watch?v=HGAWk2Z6OJQ at 720p. The videos do not have a 60fps version, so the warning is useless. It would be nice to be able to click an X and make the warning go away if I don't care about it.

Of course, it would be better if the error just didn't appear at all. Maybe you can look into what is causing the app to think it's not working. I get no errors on other videos.

I do note that the image is mostly static, only with two fades. Maybe that has something to do with it.

I do not know how long this has been a problem. I usually only watch these videos on embedded players. It may be related to the Sept 6 update, and it may not. I may be able to do regression testing in the future.

Hi. Thanks for the report! And thanks for not downvoting, and giving me a chance to fix the situation instead. I appreciate it.

It doesn't matter if that particular video doesn't have 60fps. We can't ignore the injection just because some particular video doesn't have a 60fps stream. Because the user may go into fullscreen on that video, and then when the video ends they'll get another video (or they click a suggested other video) and it'll seamlessly begin playing that video in high-FPS mode inside that exact same fullscreen player, since that player's high-FPS mode wasn't blocked by us. So even if the 1st video we visit isn't high-FPS, we must always block it in the player anyway.

That's why the warning has no close-button: It means that the warned tab won't block high-FPS videos.

This is how the script works: The user visits YouTube. This script is set to run-at its document-start which means that the script code is supposed to run as early as possible, in the tiny moment of time BEFORE YouTube's own code loads and enables high-FPS support. The script injects a replacement for the "supported formats?" checker function in your browser, so that when YouTube's own player checks the formats, we tell it that high-FPS is not supported. We obviously must inject the format-blocker script BEFORE YouTube enables high-FPS mode (otherwise we are "too late" and have to retry by reloading the page).

And you're right, I also get no errors on other videos which is why I didn't know this problem existed. It turns out that something on that video-page is extra heavy, and delays YouTube's video format checking longer than usual, so that we give up too early as "YouTube didn't use our injected format blocket, we must retry"...

I will soon release a new version which raises the "give up"-delay from 0.25s to perhaps 1s. I need to tweak the value and balance it somehow... Perhaps I will make the first reload in 0.5s and the second in 1s, etc. I'll have to investigate. Expect a little while for the update, but if you wanna "fix" it quickly in your own locally installed copy of the script right now, you can go into the code and replace the number "250" with something like "1000". :-)

PS: I did some quick investigation, and found that although my previous (v1.4 and earlier) method of checking for "window.ytplayer" no longer works (which is why I had to rewrite everything to use timers instead), I found that looking for "window.ytplayer.config" (a property of the player object) MAY be a way to detect early success without needing a carefully tuned timer. That "config" property is missing while the player is loading. If my theory is correct, the "config" property doesn't exist until their format checker has executed. So I may be able to rewrite the code to use a hybrid of checking for "window.ytplayer.config" as a sign of successfully injecting early enough, and then using some longer timers just as a secondary protection (which wait like 5 seconds and then checks that our injected format blocker has been used by YouTube), which - if this theory is right - will eliminate ALL "wrongly detected failure" reloads. I am hopeful that this method will work. It depends on if "config" only exists after they've queried formats. We'll see. It would be great if that's the case!

- Johnny

Hey, I just began work on this now, and started doing research inside YouTube's code to look for ways to determine injection success without needing to wait for an unreliable timer. I came up with the idea of inserting a console.trace() to see what exact YouTube script is responsible for checking for high-FPS format support.

As expected, it was a mess (about 50 different functions calling each other in a row, all with different obfuscated names like "Yn" and "gX" and so on), so not much luck there...

Except... Great news for everyone using this script! I saw that the whole stack trace BEGINS with the "window.ytplayer.load()" function. So we don't have to care what specific, deeply-internal function is doing the format check. All we need to "somehow" figure out is: Has "window.ytplayer.load()" executed yet? If not, then we're definitely injected early-enough!

And here's where it gets really good! There's an easy way to figure out if it has executed yet! Because I just discovered that window.ytplayer is an empty (or totally missing) object in the early moments when we've just injected into the page. It's only filled with the the actual "load" function and "config" array much LATER during the execution of the YouTube page's own scripts, which THEN "populates" the window.ytplayer object and runs its "window.ytplayer.load()" function.

In english, it means: As long as window.ytplayer is an empty object, it means that we've successfully injected very early (before YouTube's own code has executed), which means that YouTube CANNOT have executed its "load()" function yet since it doesn't even have one yet, and therefore, format checking CAN'T have happened yet! Bingo!

So that's awesome news! I'll now be able to write something like "if window.ytplayer is totally missing, or window.ytplayer is an empty object, then we KNOW that we've injected early enough and won't have to retry".

In past versions of this scripts (1.4 and earlier), I actually used something almost like that. I used to check "does window.ytplayer exist?" to determine if "we injected early enough?", but recently the script broke a few weeks ago. This new research today reveals why: YouTube has basically changed their site code a bit so that the window.ytplayer object now always exists on the page from the moment the page is opened, as an empty object. That's why the old, much nicer code failed (window.ytplayer suddenly always existed, which we treated as a failure, so the old script broke completely). But with a simple tweak, I'll be able to restore that level of performance again, by now simply checking "if window.ytplayer is missing, or it's an EMPTY object, then we've succeeded!". Lovely!

I'll keep working on this and do a really nice and reliable rewrite of the injection success checker. Probably out later today.

Almost done... this rewrite is turning out to be excellent. Even better than the older versions. Thanks to the new discovery, Chrome no longer needs any page-reloads at all. Safari, which used to need 1 reload on most videos, now only needs reloads if a link was opened in a background tab (which screws with Safari's userscript loading). And compatibility with any other browsers such as Firefox should be improved now as well. Not sure about Opera, which another user reported about, but hopefully this fixes that one too.

I'll release 1.7 today.

Alright, v1.7 is out with the new, final detection method. I'm glad this technique was possible, because it made the script rock-solid. It's like the best of v1.4 and earlier (before YouTube's redesign broke that one), and the best of the v1.5+ timer-based solution. Now we have both, as a hybrid:

1. First, my script checks if YouTube's player code is already loaded (via the new, reliable technique I finally came up with). If we see their code, it means the web browser failed to inject us early enough. If so, then we instantly reload the page to try again.
2. After that (if we see that YouTube's player code hasn't been loaded yet), then we know that we've been executed early enough by the browser, so we proceed and inject our format blocker.
3. Lastly, we wait a few seconds (12 seconds, actually) and do a final success-verification to see if the formats were truly blocked. If not, then we treat it as a failure and reload the page to try again. But this step should never be able to fail (which is why the timer is so long now), since the 1st step made sure that we're definitely injected before YouTube's high-FPS format check has ran. This final step is just a nice, extra safety check just in case there's ever a scenario where it can happen.

You can go ahead and download v1.7 now. It's now completely reliable for all videos. Enjoy! :-)

PS: I'd appreciate if you edit the topic to change the Yellow rating to Green now. You can do it by clicking the cog-wheel in the upper right of your 1st post, and clicking Edit to set a new rating. ;-)

Sure, I can flip it to green since you fixed this, and apparently made it more robust. I have tested and it appears to be working without the error message.

That said, I still would like the ability to hide the error message after I've seen it, in case I decide that I want to continue watching the video anyways (at a lower resolution, usually). It gets in the way in theater mode.

Sure, ideally I should never have to use that feature, since it should never produce an error. But it would be nice. Even if you don't want it to close all the way, maybe let it minimize to a small warning icon on the far right, that you can click to see the full message?

Still, that makes this now just a feature request, so I have now changed the review status to Good.

@trlkly Hi. Actually, after this update's improvement to success-detection (which solved all misdetections), you won't see the message anymore in Chrome or Firefox. Because both of those browsers are very early at successfully running userscripts before YouTube's own code has had a chance to run. And Chrome even handles background-opened tabs perfectly.

And even in Safari, which is pretty bad at injecting userscripts early in some scenarios (such as background tabs, and while the browser is heavily overloaded), the new update's vast improvements mean that I've only ever seen it need 1 retry (and the message shows up if 3 attempts fail), and Safari always succeeds on the second attempt, so no message is needed even in Safari.

The problem that caused you to see a message in Chrome on some videos was that the previous v1.5 detection method (which was implemented a week ago as an emergency fix after YouTube's site rewrite) had to rely entirely on timers, which was impossible to tune for both performance (reloading the page super quickly and unnoticeably if there is a real problem), and reliability (the timeout waiting long enough that even slow computers/certain heavy pages have a chance to run fully). But thanks to the new method described in my previous post, we now have the best of all worlds.

So no need to worry, it should now be practically impossible to get the message anymore in any good browsers such as the ones I listed. Especially not in Chrome, which is a great browser. So have fun and enjoy. :-)

- Johnny