Update player.js faster more reliable autoplayDisable

[raszpl]

Pause immediately after play without relinquishing js event loop queue spot (previous settimeout gave browsers opportunity to delay pausing)
Call html video element pause() first, it seems faster?
Finally remove autoplayDeniedOnce. YT is autostarting most videos couple of times, autoplayDeniedOnce was breaking autoplayDisable.

Final result is our autoplayDisable no longer plays up to couple seconds before pausing. Added bonus of moving autoplayDisable below calling original.apply(this, arguments) is any problems in autoplayDisable can no longer prevent/break Play.

[raszpl]

settimeout gave browsers opportunity to delay pausing

this function

This comment was about original setTimeout(function () { player.pauseVideo(); });

, retries, in case defining player fails

no it doesnt :)

, with no side-effects

with no effect at all

. responding to your commit for #2137. Did you actually see it's log happening? "autoplayOff is waiting for..." (if so we should watch timing for this and more features.

Have you tested your hyphotesis? Edit :

youtube/js&css/web-accessible/www.youtube.com/player.js

Line 9 in 96879c6

(function waitForPlayer(){if(player=this.elements.player||videoElement.closest('#movie_player')){return;}

to read
(function waitForPlayer(){if(player=this.elements.player1||videoElement.closest('#movie_player1')){return;}
this will always evaluate false because this.elements.player1 doesnt exist and neither any '#movie_player1')
now test this code in a debugger :) I already listed 4 problems with it in 2df3a5e

1 you cant block a functions progress by calling settimeout, it just skips it and continues
2 even if you made it work with clever async/await you should never block event handlers like that, it would freeze UI
3 we are already in a .play() event handler, that means VIDEO element already exists thus videoElement.closest('#movie_player') is sufficient. If .closest('#movie_player') doesnt exist we arent interested in pausing such play event anyway.
4

youtube/js&css/web-accessible/www.youtube.com/player.js

Line 13 in 96879c6

}else if(tries===4){console.error("resigning autoplayOff after 1.5s")}

if(tries++<4){}else if(tries===4) {} will never execute Else clause because var++ is evaluated pre increment, thus you execute (3<4) else (4===4) and on the next loop (4<4) else (5===4) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Increment

tldr: javascript doesnt work like that. This

youtube/js&css/web-accessible/www.youtube.com/player.js

Lines 9 to 14 in 96879c6

	(function waitForPlayer(){if(player=this.elements.player||videoElement.closest('#movie_player')){return;}
	else if(tries++<4){
	console.log("autoplayOff is waiting for ImprovedTube.elements.player or #movie_player");
	setTimeout(waitForPlayer,500);
	}else if(tries===4){console.error("resigning autoplayOff after 1.5s")}
	})()

just executes player=this.elements.player||videoElement.closest('#movie_player') and nothing else there ever matters. subsequent waitForPlayer() calls are made after handler finished executing, video is already playing, and nothing beyond line 15 will ever be executed again.

breaking functions should not break other scripts

thats why its safer to move it after original play().

[raszpl]

well this is bad, you pushed this bad code to both builds without testing it
(function waitForPlayer(){if(player=this.elements.player||videoElement.closest('#movie_player')){return;}

crashes because this of waitForPlayer() is not ImprovedTube, making this.elements undefined and this.elements.player crash

Despite changing order it randomly breaks pause, this is a good time to pull the update
fix #2282