Comment by lifthrasiir
2 years ago
That is not correct. The surrounding code gives some more context:
h=document.createElement("video");l=new Blob([new Uint8Array([/* snip */])],{type:"video/webm"});
h.src=lc(Mia(l));h.ontimeupdate=function(){c();a.resolve(0)};
e.appendChild(h);h.classList.add("html5-main-video");setTimeout(function(){e.classList.add("ad-interrupting")},200);
setTimeout(function(){c();a.resolve(1)},5E3);
return m.return(a.promise)})}
As far as I understand, this code is a part of the anti-adblocker code that (slowly) constructs an HTML fragment such as `<div class="ad-interrupting"><video src="blob:https://www.youtube.com/..." class="html5-main-video"></video></div>`. It will detect the adblocker once `ontimeupdate` event didn't fire for 5 full seconds (the embedded webm file itself is 3 seconds long), which is the actual goal for this particular code. I do agree that the anti-adblocker attempt itself is still annoying.
For the completeness, the omitted Uint8Array is the following 340-byte binary (here in base64):
VLC somehow refuses to play it, but its nominal length can be verified with a short JS code like:
I couldn't reproduce the 5s wait in multiple scenarios in Firefox (various combinations of being logged in / not being logged in / without adblocker / with adblocker) and couldn't reproduce a 5s wait time in any of them, it played back immediately in each case (when without adblocker, using a second video to have one start without ad). I tested on Linux.
What exact combination of circumstances is required to trigger the multi second wait time?
I just tested this in firefox on ubuntu. Three subsequent new tab tests.
Load: 4.34s, 5.14, 2.96, 3.35
DOMContentLoaded: 3.65s, 4.56, 2.92, 3.33
Finish: 13.14s, 10.77, 8.49, 12.02
So it's getting a bit faster over time, but still heinous, and crucially, it isn't hanging on requests. Individual asset GET/POST requests are taking tens of ms, worst was a few parallel 254ms GETs on a cold start. Usually 50-70ms. But there is a flurry of requests, then a period of very few requests until 5s after init, then another flurry.
Firefox 119.0 Ubuntu 22.04 uBlock Origin, Privacy Badger
Same OS, chrome 115.0.5790.170, no blockers, youtube is much snappier, it still definitely takes a few seconds to paint thumbnails, but it's basically done by 5s. DOMContentloaded is never more than 1.75s, finish <8s.
Firefox private window with blockers off has similar time statistics. But actually doubleclick.net is still getting bounced.
I tested in Firefox (uBlock), LibreWolf (uBlock), Safari (AdGuard), and Chromium (no ad blocker), and the initial home page load takes a couple seconds, but I never witnessed a 5s delay. I would say it was actually fastest in Firefox for me, but that may have just been a result of some caching. I am a premium subscriber and have never seen a warning for using an ad blocker, so I'm not sure if premium subscribers get a pass.
I can't reproduce this either. YT on FF plays immediately for me
I am experiencing delay on both Firefox and Waterfox
It is still better to wait 5s without ad than with ad.
It has to be a background check, otherwise you can't explain cases (like me) where the code is running but users never noticed any delay.
I wonder if it is just a coincidence that 5s is the time before a skippable ad becomes skippable?
Either wait 5 seconds without ad, or get served an ad about switching to Chrome
Okay, I'm sold on the delay, but where's the code that detects non-chrome?
Do they serve different js based on the user agent header? If they delay chrome too there's no foul.
Just going off this tweet, it seems to be user-agent based: https://fixupx.com/endermanch/status/1726605997698068630
If YouTube are going to go down this path, then perhaps Firefox devs should set the user agent to Chrome for YouTube?
They delayed chrome too. At least for me.
Why is it only trying to detect ads when the user agent is Firefox?
https://old.reddit.com/r/firefox/comments/17zdpkl/this_behav...
Probably because there are other methods for Chrome that don't apply to Firefox.
Like when I noticed that some sites did some URL rewriting trickery on Firefox and others browsers, but not for Chrome. The trick is to show you the proper URL the link points to, but as you click, it is substituted for one that is a redirection, for tracking purposes (ex: "https://l.facebook.com/l.php?u=http:://actualsite..."). On Chrome, they don't need to use these tricks as the browser supports the "ping" attribute of links, so they can do their tracking without rewriting the URL.
This kind of BS is why I don't ever click on links directly. I copy/paste them instead, so I can examine and trim them. Often, the actual link is through some sort of redirection service and I need to copy/paste the text the browser shows for the link rather than the actual link.
There's so much trickery and nonsense around this stuff that no link is safe to just click on.
5 replies →
I've also noticed this behavior popping up a lot lately, but I had no idea why. The URL with tracking included was still blocked by uBlock Origin, but having to manually copy-paste the relevant portion was an annoyance.
Thanks for the context!
1 reply →
Wow, that is pretty disgusting behavior.
1 reply →
I have no idea because I didn't experience anything like that both in Chrome and in Firefox (both with uBO though). But I'm confident that this particular code is not related to the actual slowdown, if it did happen to some Firefox users, because I received the same code even in Chrome.
Does Firefox allow a wider range of plugins, including adblockers?
Yes, Chrome is severely hobbled in this by comparison.
Yes, there are plenty. You can have a look here: https://addons.mozilla.org/en-US/firefox/
This is just anecdote, but sometimes (especially when I'm on slower internet) Safari + AdGuard will have glitch [0] on YouTube. Never happened with Firefox + Ublock Origin.
[0] Unable to press play and showing image with Ad instead.
I experience the same glitch and i like it because you can just reload the page (cmd-r) and then the video starts so if you're used to it you can skip ads within less than a second and you dont get annoyed by the ad sound/video, just an image.
I would suspect because Google can do the detection in Chrome itself, but not in Firefox.
if it’s anti-adblock, does it run even with premium?
[dead]
[flagged]
This gives us some background, but it's still slowing down firefox with no relation to the video content.
It's radically different.
How come switching to User Agent to Chrome fixed it for that Reddit OP? Does it omit this if UA is changed?
When they first introduced anti-adblock crap, you could evade the banner by switching UAs. I'd say it's fair to assume that switching UAs triggers some other code path and this function never gets called.