Bug on the unhidden progress bar

[snintendog]

Does not update position or time code until hovered over youtube added .ytp-progress-list .ytp-load-progress .ytp-hover-progress ,ytp-play-progress under .ytp-progress-bar

[mechalynx]

This smells like a javascript problem although I haven't investigated in depth yet. I say this because, if they expected the player to operate with their own auto-hiding, they'd most likely stop updating hidden elements for performance reasons and there's been a lot of performance optimization in their updates it seems.

I have looked a bit into the minified code and there are event handlers for hovering on and off the player from what I can see, which may imply I'm correct, but it's a huge file and it slows vim+ternjs down so I need to do this manually.

Unfortunately, I won't have time to work on this and figure it out for the next few days, but I'm pretty sure, if indeed this is the cause, that I can do something about it or at least determine for sure if it's the javascript or if it can be solved through css.

[snintendog]

I have noticed the aria for the bar stops updating when it goes into hide mode so if we could go and find what causes the hide and just disable/unload it that may have the desired effect rather than just getting rid of the transparency it causes but no luck on my side in find that in that mess of a file yet also thanks didn't expect a reply was just putting any bugs i find here so i don't forget them.

Would also like to note that Youtube - Right Side Description (Aka Better Watch Page) seems to be making some head way with their retro mode as well this bug happens to their script too.

[mechalynx]

The problem really is that the source file for the player is a self-executing anonymous function, which means it leaves no available reference and there is no access to its internals - thus, if the behavior is hard-coded into that closure, we have no way of affecting it. I've written stuff where I have to rewrite functions on websites through scripts, but this is for all intents and purposes impossible with page-level code (which is what a userscript is).

There might be a slight chance of overriding the behavior if we did something like an overlay that intercepts all mouse events and relays everything to the player except the hover events. We could then tell it we're always hovering and use css to adjust the player's controls so that they fade or move down so only the progress bar is visible (this is how it used to be right?). At this point, I don't see much in the way of alternatives, since the player's code is inaccessible from javascript.

The css should be easy, I've done a quick test here: http://jsfiddle.net/bqvxsdsp/ - my previous test was with moving it up or down, it's not a problem.

[snintendog]

The guy that made Youtube New UI Fix (https://greasyfork.org/en/scripts/11485-youtube-new-ui-fix) fixed it using the code that is below got any ideas without resorting to this? var evObj = document.createEvent('Events'); evObj.initEvent("mousemove", true, false); var moviePlayer = document.getElementById("movie_player"); setInterval(function() { moviePlayer = moviePlayer || document.getElementById("movie_player"); moviePlayer.dispatchEvent(evObj); }, 1000);

[snintendog]

Find a Way to disable auto hide at its source rather than having the player think a mouse is hovering over it constantly.

[mechalynx]

There is no other way. In fact, this is a better way than disabling it at the source, even though it feels like a terrible way to do it. Here's why:

1. We can't disable it at the source. The player's code is enclosed in an anonymous, self-executing closure. This means we have no way of accessing any of its internals, except if we have debugging access to the javascript interpreter itself (which we don't because this is page javascript and we wouldn't have this power even if we had chrome privileges, which means an extension). It can't be done, plain and simple.
2. If we were to do it, assuming it were possible in the first place, it would be very prone to breaking whenever they change their code. It would mean that we'd have to keep an eye on all their code changes, just in case the javascript minifier decides to give whatever we're using a different name. It would be too much work and too easy to break. Doing it this way means that all we're depending on is that the intended behavior of the user interface remains the same, which is very likely. Even if it did change, hovering constantly would only cause problems if it actually produced behaviors that are strange, such as hovering causing the player to stop or something weird like that.

So in summary, this isn't just the only way to do it, it's the way to do it in our case where we're trying to alter behavior of a UI who's implementation we don't control. It's least likely to break and the most polite way of doing it.

Now, if you're concerned about performance, it won't be an issue. The timeout on the dude's code is 1 second, which for a computer is a few centuries. It won't cause any lag or delay or anything of the sort. If you where to move your mouse manually over the player every second, it would cause more code to execute, in fact.

Optionally of course we can add an option checkbox to disable this and have it on by default since users installing this would likely want the old behavior as it was. It would solve the case where it somehow does cause problems.

[snintendog]

Yeah that makes sense and being able to disable options have always been a favored feature of mine for just about anything. Thanks for explaining the problems with my flawed logic.