Removes the autoplay up next feature

Disable_Youtube_Autoplay.user.js

// ==UserScript==
// @version  02--2017.09.12
// @name     Disable autoplay next in Youtube
// @description Turns off autoplay next video in Youtube after a few (WAIT_SECS) seconds when you first (re)load a page.  You can toggle it back on anytime, if you want to go jukebox mode, and it will stay on as long as you don't reload the page.
// @match    *://www.youtube.com/*
// @run-at   document-idle
// @noframes
// ==/UserScript==
(function () {
    'use strict';

    var SCRIPT_NAME = 'Disable autoplay next in Youtube';
    var WAIT_SECS = 3;

    function disableAutoPlay() {
        // Toggle AutoPlay button if it's enabled
        if( document.getElementById('toggle').active ) document.getElementById('toggle').click();
    }

    // Wait for the Next videos section to load
    // Obsolete events are not working (readystatechange, spfdone), as expected.
    // Couldn't get new ones to do it either (yt-navigate-* only seems to trigger after navigating to *another* video).

    // Good old timeout does the trick tho
    setTimeout(disableAutoPlay, WAIT_SECS*1000);
}());

Hi Jeff! I would be happy to obligue you if we were talking about any significant piece of code, but you're talking about two lines of obvious code in a simple Monkey script thrown in a disposable gist... imagine if we were to give credit for every little line we lift from Git, StackOverflow or a tutorial. Specially when you're starting out: you would waste more time and lines in credits than in code!

Not to demerit your effort, but I gather it was more learning than coding. And just like with my rock band, I would suggest to focus on learning and producing better material before thinking of credits and recordings. ;)

Anyway, it took me a whole minute to right click the toggle bar, glimpse its properties and find a more elegant one-liner to replace your two lines, which were hard to read. You (and everyone else) are welcome to copy it, no questions (nor credit) asked. :)

Including the original gist, of course I would make a pull request if I could, but you see, even GitHub promotes simple copy-paste of simple short scripts.

Cheers!

Forget I said anything. I get paid enough to write functional code on real projects, and to deal with cocky devs like you. Glad you found your own "elegant one-liner", too bad it doesn't work. It only changes the cosmetic attributes of the toggle, it doesn't turn off the actual autoplay feature. Nice try though. You'll notice my working script is now gone, so you can try again, and do "more learning than coding".

Also, if Github isn't about code accountability and credit, then why does every diff, even if it's only one character, have an author? Have you ever worked with a team on a large private repo with real intellectual property? I'm not so sure, if you had, you might respect others work.

If you are as good an engineer as you purport to be, then you know exactly how powerful 2 lines of code can be. I realize that was a simple script, however, if I took it verbatim from you, I would have said thanks and referenced you in comments, but clearly, we are different people. You're the elitist type that makes people hate our industry.

Cheers!

PS - Since you were so kind to share advice, here's some for you, using a single setTimeout as a mechanism to wait for the DOM to load is not elegant, you're creating a race condition. If the page happens to take longer than 3 seconds to load, your broken script will never act on the toggle since it won't be there yet. Also, Github does not encourage people to "lift" code, that is why the "fork" and "pull request" features exist. Lastly, you should take the time to fully test your features before you put your foot in your mouth.

Anyone is welcome to fork this one, or copy it into their script runner of choice. Uses recursion to avoid race condition on load.

https://gist.github.com/jeffmbellucci/8db3a8b27664dac6b8f9cf10b416b433

Hi again,

first than anything, I never had the intention of demeaning you, much less so make you angry. I wrote my answer with all the good intentions I profess in and out the keyboard, so I was quite a bit surprised by your last bit. I'm not sure if it was the smileys, a platonic sense of justice, the frustrating coworkers you mention or the limited expressive nature of text that twisted what I see as an honest-but-friendly to cockiness, but again, I would never provoke such reaction on purpose, so, for what it's worth, I'm sorry for that.

My points still stands though. You have to draw a line on how much nitpicking you'll deal with, and I guess mine is higher than yours. We are talking about a small hack with a minimal impact in the world, that will break with the next Youtube refactoring. That's very low on my scale.

Learning, on the contrary, is very high, so for me learning or stating someone does it is never a bad thing. I did assume you were new to JavaScript and friends, however, seeing you quiz two elements when one would suffice, and query accessibility values instead of proper properties. Perhaps you aren't, but still, you had to learn to find your solution, by your own admission, and that's all I stated. I'm sure Google is still a big tool in your own field.

On the other hand, the assumptions you make about me are a bit more extreme; and mostly wrong, I'm happy to say.

So, I hope things are a little more clear now. And if not, oh well, we both have better things to do in any case.

Cheers.

P.S: thanks for the advice.

I appreciate your clarification. I'll delete my comments from the more public arena, aside from the one with the gist. Like you mentioned about taking little time on your re-write, initially, I spent only a few minutes fiddling in the console, to help make a working script again, I didn't refactor, or think that much about code quality.

Multiple people thanked the original author, which I think is appropriate, and I do my best to give credit where credit is due. I do think this field lacks a certain amount of mutual respect, and I have found over years of working with many devs, that there is a constant one-upmanship and concerted attempts to find flaws in other's work. I'll never understand that. I don't think it fosters cooperation or makes people want to join our field.

I studied economics and computer science in college, but graduated into the dotcom bust, so I chose to pursue EMS instead of development after school. About 5 years ago, I went back into the software industry because it was burgeoning again. Coming from being a paramedic and firefighter, where teamwork and positive communication is so important, I find the culture of software development frustrating much of the time. It has nothing to do with thick or thin skin, no one will bust your balls more than medics, cops, and fire guys. I find that type of negativity in software development counterproductive.

Anyway, you're more than welcome to code review my gist/script. I rewrote it to be more readable, from my point of view anyway. I know it's possible to make it shorter, I wrote it to make it clear, but people have different opinions on whether condensing code is a good or bad thing. More generally speaking, I won't make anymore assumptions about you, and I have no interest in a pissing match or trying to prove who is the most awesomest software superstar.

Take care.