Update functions.js click is always user_interacted

[raszpl]

No conditions, let user always override pausing. #2042 (comment)

[ImprovedTube]

hi! @raszpl,

• yes, if(ImprovedTube.elements.player.classList.contains('ad-showing') === false) was redundant (since it is i autoplayDisable)
• better for autoplayDisable() : if ( !user_clicked_play_or_player_or_hit_space_or_k_or_a_custom_hotkey_to_play
  • alternative to checking compasedPath: if ( ImprovedTube.elements.player.contains(event.target)
    • (can't edit the files in Update functions.js click is always user_interacted #2431)

user_interacted

this could ignore clicks on whitespaces (usually by mistake):

if (!user_interacted){
 if (!/^(primary|secondary|below|masthead|dismissible|panels|chat-container|donation-shelf|player-ads|guide-content)$/.test(event.target.id) 
   && !/^body|YTD-(TWO-COLUMN-BROWSE-RESULTS|SEARCH|GUIDE-ENTRY|MINI-GUIDE|REEL-SHELF|WATCH-NEXT-SECONDARY-RESULTS|AD-SLOT)-RENDERER$/.test(event.target.tagName) 
  ){
user_interacted=true
}

and for keydown it could depended on the key being an existing hotkey - or focused inside an input.

---

autoplayDisable() can also require that the page was loaded or navigated or activated/viewed within the last few seconds.

meant: player.pauseVideo() if (Date.now() - pageTime < 2000) { player.pauseVideo() } for player.js#L29
and:

let PageTime = 0;
function setPageTime() { PageTime  = Date.now(); }
document.addEventListener('DOMContentLoaded', setPageTime);
window.addEventListener('load', setPageTime);
window.addEventListener('focus', setPageTime);
window.addEventListener('popstate', setPageTime);
let urlEarlier = location.href.split(/[?#]/)[0]; 
function checkUrlChange() { const URLnow = location.href.split(/[?#]/)[0];  
      if (URLnow !== URLearlier) { URLearlier = URLnow; setPageTime(); }    
};
setInterval(checkUrlChange, 300);

(to be included in our existing event listeners and or consider youtube's events too like they do)

[raszpl]

• better for autoplayDisable() : if ( !user_clicked_play_or_player_or_hit_space_or_k_or_a_custom_hotkey_to_play

As long as user clicked any key or mouse it should be enough a signal, this is how all "disable autoplay" extensions I looked into do it. It doesnt really matter where user clicked, click = stop forcing Pause.

(can't edit the files in Update functions.js click is always user_interacted #2431)

after #2384 (comment) I rather you not directly edit my patches and push them under my name :P

user_interacted

this could ignore clicks on whitespaces (usually by mistake):

The issue is it now requires waiting for player to load, in my testing I would start loading /watch page, click in the spot where video was being rendered and .. nothing would happen because user_interacted wasnt flipped true by my click just because I clicked a split second too early.

autoplayDisable() can also require that the page was loaded or navigated or activated/viewed within the last few seconds.

#2421 (comment)
"I think we already talked about this. Someone loads page in the background tab = YT will autoplay only after switching to that tab, user switches to the tab after few minutes, settimeout would make that autoplay pass."

setInterval(checkUrlChange, 300);

"Every time I see a workaround with setimeout its another problem"
"Every time you want to use settimeout just start with the assumption its a bad idea :-]"
that goes even harder for setinterval :)

(to be included in our existing event listeners and or consider youtube's events too like they do)

What is the reason for that checkUrlChange running constantly in the background? we dont have problem with detecting YT URL change.

Anyway all the pausing pains are going away when I finish cooking my local changes. Instead of trapping HTMLMediaElement.prototype.play which happens already too late my local version listens to document.addEventListener('loadstart' and overrides Youtubes own ImprovedTube.elements.player.playVideo() . Works great if one always wants paused videos - Videos never start playing, not even for a millisecond. With this change Extension would universally pause ALL videos until extension settings load and are properly initialized, and only then decide if we want to Play. In effect making all "autoplay" options really work as they sound, no more "force autoplay off", now ImproveTube would really be deciding if to Autoplay or not. I havent started writing the Play() function yet, I think 'yt-navigate-finish' would be a good point to start playing.

[ImprovedTube]

Anyway all the pausing pains are going away when I finish cooking my local changes. Instead of trapping HTMLMediaElement.prototype.play which happens already too late my local version listens to document.addEventListener('loadstart' and overrides Youtubes own ImprovedTube.elements.player.playVideo() . Works great if one always wants paused videos - Videos never start playing, not even for a millisecond. With this change Extension would universally pause ALL videos until extension settings load and are properly initialized, and only then decide if we want to Play. In effect making all "autoplay" options really work as they sound, no more "force autoplay off", now ImproveTube would really be deciding if to Autoplay or not. I havent started writing the Play() function yet, I think 'yt-navigate-finish' would be a good point to start playing.

💡

[ImprovedTube]

user_interacted
this could ignore clicks on whitespaces (usually by mistake):

It doesnt really matter where user clicked, click = stop forcing Pause.

that can be called any_HID_input (,while i prepared user_interacted for later.)

user_clicked_play_or_player_or_hit_space_or_k_or_a_custom_hotkey_to_play
this is how all "disable autoplay" extensions I looked into do it

we can implement more details.

"I think we already talked about this. Someone loads page in the background tab = YT will autoplay only after switching to that tab, user switches to the tab after few minutes, settimeout would make that autoplay pass."

not what i said.

SetInterval

universal example code.

(to be included in our existing event listeners and or consider youtube's events too like they do)

we dont have problem with detecting YT URL change.

both of our lines say the same.

@raszpl