Greasy Fork is available in English.
Removes unneeded parameters and redirection pages from YouTube links.
< Feedback op YouTube Link Cleaner
I cannot reproduce your problem. I have done following steps:
Seems YouTube checks the left-click and modifies process from there on.
Yes, YouTube overrides the behaviour on the left-click. It replaces the page content without loading a new page. You can see that the page content is replaced if there is a red progress bar at top of the page.
So 'YouTube Link Cleaner' handles that
It removes the class names "yt-uix-redirect-link" and "spf-link" from the links to force loading a new page. The reason is that the scripts are automatically executed at page loading. When the page content is refreshed, the scripts are not executed automatically.
I've just installed again and latest Version 5 ... and problem remains when link called from a section, channel, user ...
From https://www.youtube.com/ ; works
From https://www.youtube.com/user/AviationWeek : does not work, SPF is not blocked
After trying your script I found a Firefox add-on as well as a userscript which both run successfully :
YouTube ALL HTML5 :: Add-ons for Firefox AT https://addons.mozilla.org/en-US/firefox/addon/youtube-all-html5/
YouTube - Disable Red Bar aka SPF | Scripts | OpenUserJS AT https://openuserjs.org/scripts/JoeSimmons/YouTube_-_Disable_Red_Bar_aka_SPF
I've read your own experience which showed no problem. Therefor at this time I guess there is possibly a compatibility issue with either one of my other scripts, either with one of my Firefox add-ons. Don't get me wrong therefor : your script is fine, well crafted, the issue is one of compatibility, very likely.
I stay tuned.
Seems to me that part of the reason it's not efficient is because it keeps running the ChangeLinks
function every second, with this:
window.setInterval(ChangeLinks, 1000);
I don't think it has to run every second. Just deleting the yt-uix-redirect-link
class from the hyperlink should be enough to stop it from changing the links.
Actually, I don't think there are any negative effects from simply removing the class attribute from all links.
Also, I think the if statement before the for loop is completely unnecessary:
if(LinkCount != window.document.links.length)
Basically, I would change the function to this:
function ChangeLinks() {
for (var i = window.document.links.length; i--;) {
/* Remove unneeded parameters */
window.document.links[i].href = window.document.links[i].href.replace(/(&(feature|src_vid|annotation_id|gl|hl)=[a-zA-Z0-9_\-\.]*|\?(feature|src_vid|annotation_id|gl|hl)=[a-zA-Z0-9_\-\.]*$)/g, '');
/* Do not use redirect pages, disable AJAX on links */
window.document.links[i].removeAttribute("class");
}
}
ChangeLinks()
And delete these:
LinkCount = 0;
window.setInterval(ChangeLinks, 1000);
Seems to me that part of the reason it's not efficient is because it keeps running the
ChangeLinks
function every second, with this:window.setInterval(ChangeLinks, 1000);
I don't think it has to run every second.
There are cases in which links are dynamically added, for example after pressing the "Show more" button in the Related videos column or after pressing the "Load more" button on the video list of a user. If you run the function only once, you don't catch these links.
Also, I think the if statement before the for loop is completely unnecessary:
if(LinkCount != window.document.links.length)
If you run the function only once, this statement is really unnecessary. But the function is called every second, so this statement is used to avoid walking through all links if there are no links added.
If you want the function to run again after the page has changed, you might be better off using an EventListener:
document.body.addEventListener("change", ChangeLinks, false);
Or a mutationObserver:
var observeChanges = new MutationObserver(ChangeLinks).observe(document,{childList:true,subtree:true});
It's probably better to use the MutationObserver.
Just add one of them in place of window.setInterval(ChangeLinks, 1000);
edit: OK, I just discovered that removing the class from all links causes most buttons on the HTML5 player to disappear (except play/pause).
if (links[i].className.contains("yt-uix-redirect-link") || links[i].className.contains("spf-link"))
links[i].removeAttribute("class");
The solution with the MutationObserver
in the posting before was even more inefficient than my old solution, it has freezed my browser.
I have found another way to disable SPF. It does not have the need to watch and change links. (And it also disables the redirect pages.) So I have changed my code to this solution.
Just installed version 7 and it runs flawlessly -> Thanks a lot tfr for your work and commitment.
SPF is really a pain in the neck. Now I can open a video in the same tab without having to endure this absurdity.
Have a great week :)
I'm not sure why it would freeze your browser, but glad you found a solution.
edit I just tested your script, and it looks like it still does have link redirection. Even though the link appears to point to the plain URL, if you click on it the browser will still navigate to a URL with "www.youtube.com/redirect?q=*" So I think deleting the class name "yt-uix-redirect-link" is still necessary.
Also, I think you can shorten this:
if(window && window._spf_state && window._spf_state.config)
to just this:
if(window._spf_state.config)
Because window && window._spf_state
should always be true anyway whenever window._spf_state.config
is true
Also, I think you can shorten this:
if(window && window._spf_state && window._spf_state.config)
to just this:
if(window._spf_state.config)
Because
window && window._spf_state
should always be true anyway wheneverwindow._spf_state.config
is true
No. It's throwing an exception. Open Firefox Web Console (Ctrl+Shift+K) here at Greasy Fork.
The solution which you propose throws an exception.
I'm not sure why it would freeze your browser, but glad you found a solution.
I just tested your script, and it looks like it still does have link redirection. Even though the link appears to point to the plain URL, if you click on it the browser will still navigate to a URL with "www.youtube.com/redirect?q=*" So I think deleting the class name "yt-uix-redirect-link" is still necessary.
It really has shown redirect pages. (Also in my test today.) When I tested it before two days, it has not shown redirect pages.
I reimplemented the removement of "yt-uix-redirect-link". Please update again.
The exception isn't there whenever I'm on a youtube page (Opera 31 x64 and Firefox 40 x64 on Linux).
If the script is allowed to run on pages other than youtube then I would expect to see an exception (since the window._spf_state.config variable probably won't exist elsewhere).
Another possibility is if youtube randomly chooses who should have SPF enabled (they've done that kind of thing before for experimental features), the variable might exist for some people but not others.
edit Actually, it might even be easier just to set window._spf_state to null:
window._spf_state = null;
And you wouldn't even have to test if it exists first.
The exception isn't there whenever I'm on a youtube page (Opera 31 x64 and Firefox 40 x64 on Linux).
You can't expect there is a window._spf_state
in all cases. For example:
window._spf_state
. I tried https://www.youtube.com/embed/... and there is no window._spf_state
.If the script is allowed to run on pages other than youtube then I would expect to see an exception (since the window._spf_state.config variable probably won't exist elsewhere).
The problem is: The script would stop working at the time it throws an exception.
Actually, it might even be easier just to set window._spf_state to null:
window._spf_state = null;
And you wouldn't even have to test if it exists first.
I have tried it with the Firefox Web Console, and it hadn't worked. The red bar appeared.
@tfr and @Knowbody, your exchange is far above my aptitudes but most valuable as always -- Thanks to both of you.
I've just had the browser auto-update YouTube Link Cleaner to version 8, tested it on a Youtube channel and it ran perfectly.
My comment brings nothing to the debate besides a user's confirmation. This SPF seems to be truly a challenge.
Nice work (I should have tried to code, too late now!). Config here is Cyberfox 4.0.0.2 x64 / Windows 7 x64 Home
My thinking for using window._spf_state = null;
was that even if it didn't exist, it shouldn't throw an error, because it would just create a new variable with a null value anyway.
But I just had a chance to test it, and it looks like it doesn't disable the red bar.
But I tested if (window._spf_state.config) window._spf_state.config["navigate-limit"] = 0;
And it is disabling the red bar for me.
I also tested it with only window._spf_state.config["navigate-limit"] = 0;
And it also disabled the red bar, and doesn't throw any exceptions for me.
I'm not sure if youtube enables SPF for everyone. If they do, then the if statement won't be necessary, because the variable would then exist for everyone.
The problem is: The script would stop working at the time it throws an exception.
I mean, if it's running on a page that isn't youtube, it shouldn't work anyway regardless of exceptions.
edit
Well, I just did some more testing, and it seems the script does create an exception if it is set to
// @run-at document-start
I just found an easy way to disable redirection and SPF (and clean up a few other random things). The relevant links can be easily tested by their 'rel' property.
for (var i = window.document.links.length; i--;) {
/* Remove unneeded parameters */
window.document.links[i].href = window.document.links[i].href.replace(/(&(feature|src_vid|annotation_id|gl|hl)=[a-zA-Z0-9_\-\.]*|\?(feature|src_vid|annotation_id|gl|hl)=[a-zA-Z0-9_\-\.]*$)/g, '');
/* Do not use redirect pages, also disable SPF */
if (/nofollow|spf-prefetch/.test(window.document.links[i].rel) {
window.document.links[i].removeAttribute('rel');
window.document.links[i].removeAttribute('class');
window.document.links[i].removeAttribute('dir');
window.document.links[i].removeAttribute('data-sessionlink');
}
}
At minimum you could remove just the class attribute.
At minimum you could remove just the class attribute.
No. There is a stylesheet rule that actually relies on some class attribute:
.content-link {display:block; min-height:68px; text-decoration:none}
Try it out: Copy the following string in your Firefox Web Console (Ctrl+Shift+K):
for(var i = 0; i < window.document.links.length; i++) { window.document.links[i].removeAttribute("class"); }
Related videos column before:
Related videos column after:
And to your script suggestion:
rel="nofollow"
: That is not really a sign for a redirect link. It is primarily intended for search engines. Removing it would not change anything on the functionality of the page.dir="ltr"
: This is an attribute to set text direction, for example, if you write an Arabic or Hebrew text. Has nothing to do with redirect links.Well in that case you can just set the class to only contain 'content-link'At minimum you could remove just the class attribute.
No. There is a stylesheet rule that actually relies on some class attribute:
All the redirect links on youtube have that property (and nothing else does), so it's an easy way to check for them. I know that isn't what it's intended for. Removing the rel property is mainly intended for the one containing 'spf-prefetch' (and it also doesn't really have an effect for the ones containing 'nofollow', especially given that redirection is being removed anyway, so it won't affect search ranking regardless)And to your script suggestion:
rel="nofollow"
: That is not really a sign for a redirect link. It is primarily intended for search engines. Removing it would not change anything on the functionality of the page.
dir="ltr"
: This is an attribute to set text direction, for example, if you write an Arabic or Hebrew text. Has nothing to do with redirect links.
I know it has nothing to do with redirection links. I'm just looking for other things that could optionally be removed.
But I just made this anyway:
for (var i = window.document.links.length; i--;) {
/* Remove unneeded parameters */
window.document.links[i].href = window.document.links[i].href.replace(/(&(feature|src_vid|annotation_id|gl|hl)=[a-zA-Z0-9_\-\.]*|\?(feature|src_vid|annotation_id|gl|hl)=[a-zA-Z0-9_\-\.]*$)/g, '');
/* Do not use redirect pages, also disable SPF */
if (/yt-uix-redirect-link/.test(window.document.links[i].className))
window.document.links[i].removeAttribute('class');
else if (/spf-link/.test(window.document.links[i].className)) {
window.document.links[i].className = 'content-link';
window.document.links[i].removeAttribute('data-sessionlink');
window.document.links[i].removeAttribute('rel');
}
}
Stops being efficient after YouTube's homepage [FIXED]
Hi,
The scripts runs flawlessly with videos called from Youtube's homepage but fails when switching to a YouTube "section" such as News, Sports etc ...
My problem was that since yesterday morning (Sunday 2015-08-02) I noticed that when clicking a video it would be displayed correctly but at the same time would render inoperative two scripts I run (YouTube HD Override & Resize YT To Window Size). I disabled the former to test resolution with an add-on this time (YouTube HD Plus :: Add-ons for Firefox) and same issue : inoperative.
I ran 'YouTube Link Cleaner' and issue disappeared, but only on YouTube's homepage as I mentioned.
I don't know what YouTube is up to. What I can say is that if I right-click on a video link and choose 'Open Link in new tab' or 'Open Link in this tab', or if I middle-click to open video in a new tab, the issue disappears even without this script. Seems YouTube checks the left-click and modifies process from there on. So 'YouTube Link Cleaner' handles that, but then why does it fail when a video is called from a YouTube section (News, Sports ...).
I'm a bit lengthy, sorry for that, as English is not my mother-tongue.