Comment by ayhanfuat
2 years ago
From reddit discussion (https://www.reddit.com/r/firefox/comments/17ywbjj/comment/k9...):
> To clarify it more, it's simply this code in their polymer script link:
> setTimeout(function() { c(); a.resolve(1) }, 5E3);
> which doesn't do anything except making you wait 5s (5E3 = 5000ms = 5s). You can search for it easily in https://www.youtube.com/s/desktop/96766c85/jsbin/desktop_pol...
That is not correct. The surrounding code gives some more context:
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
1 reply →
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.
10 replies →
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?
2 replies →
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.
1 reply →
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.
1 reply →
How come switching to User Agent to Chrome fixed it for that Reddit OP? Does it omit this if UA is changed?
1 reply →
I'm not even mad about Google making my artificially wait 5s for using firefox.
I'm mad that such a big company with suposelly decent engineers, are making me wait 5s with literally a sleep, how is even possible to do such thing in such a rudimentary way? I would be like damn that was smart, this feels like, seriously this is the level?
IMHO, this kind of things are not done by engineers.
When company gets a backlash from public: "oops, we forgot to clean up all parameters of feature flag and it accidentally impacted Firefox"
"oops" https://www.zdnet.com/article/former-mozilla-exec-google-has...
9 replies →
Very good point. It's important to recognise that developers in many companies are often not fully aware of the intended use of features they're asked to create.
Another example that springs to mind is Uber, who used a tool called "Greyball" to avoid contact between drivers and authorities: https://www.reuters.com/article/uk-uber-greyball-idUKKBN16B0...
My initial reaction was astonishment that the engineers would happily implement this. And maybe that is what happened. But the alternative possibility is that product and senior management assigned different parts of the feature to different teams e.g. one team develops a pattern recognition system to detect users' professions, another team develops a spoofing system for use in demos, etc...
4 replies →
> * Marketing/Sales asks engineers to add a feature flag to sleep N milliseconds for their research: "how slowing down impacts your revenue"
“Research”
10 replies →
This doesn’t add up.
In order for someone to slow down the by browser they need someone to have coded the following:
- UA Detection
- Branching for when the flag is on or off
- a timeout that only runs when these two things are true
That takes an engineer to do the work. Marketing and product managers are not writing this code certainly.
If they’re abusing a differ t flag, then the real question I have is what the flags purpose is and why is it screening Firefox.
Either way there is an intention of UA checking and throttling based on the UA and that takes an engineer to do it
1 reply →
Because it works.
Good engineering isn't about being obtuse and convoluted, it's about making stuff that works.
when the purpose is to abuse your monopoly to further your business interests in another area, being obtuse and convoluted to get plausible deniability is good engineering. This is just sloppy.
7 replies →
Using an idle timer, like window: requestIdleCallback [1], is good engineering. If anything passes that's not good engineering, it's laziness.
I'm not even a JS programmer but I know about timers, idle wait in UI programming is a common pattern. It's the attitude of mediocre engineers not bothering to lookup or learn new things.
If every OS/browser/stock market dev did what they want "because it works" we don't have a working system. We'll have systemic lags making the system sluggish and eventually unusable as more engineers follow the same mantra.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...
2 replies →
Speaking as someone who only very occasionally does browser related programming, what is the supposed sin committed here by implementing it this way?
In programming in general, sleeps are generally considered....(I'm lacking the word)...distasteful?
If your code needs to wait for something, it's better done with some sort of event system or interrupt or similar; the reason being that a 5s wait is a 5s wait, but if, say the thing you're waiting for returned in 10ms, if you're using an alternative solution you can carry on immediately, not wait the remaining 4.99 seconds. Conversely, if it takes longer than 5s, who knows what happens?
6 replies →
they are a lazy man's solution to race conditions that does not actually solve the problem of race conditions, only makes them less likely to cause a problem at an often extreme cost to responsiveness as seen here.
I don't know if this is what was meant, but my assumption is that it is quite brazen and crude.
But then I think of some alternative method where they send an ajax request to "sleep.google.com/?t=5" and get a response like "" after five seconds.
Yep, curious to know the same thing myself.
For one, they didn't use React.
You're mad that they're using a function for its intended purpose?
It is not literally a sleep though, isn't setTimeout more like a creating a delayed event? (I am not a webdev)
You can't directly do a sleep in Javascript because it runs in the same thread as the UI - it would block the user from interacting with the page. This is effectively a sleep because after 5 seconds it's running the code in the passed-in function (not firing an event). The code in the function then resolves a promise, which runs other functions that can be specified later by what called the one using setTimeout.
That's Javascript for you. Don't want to block the one thread from doing other things in the meanwhile.
Maybe the engineer that was tasked with implementing was annoyed with the task and did it on purpose this way.
I'm more mad about the complete failure of regulators to break up an obvious monopoly than I am with the engineers (though they're not saints either)
At least they didn't rewrite the sleep code to do crypto mining.
Reminds me A Ticket to Tranai by Robert Sheckley where they deliberately asked to slow down robots in order for people to be angry and destroy them.
Google employs 30000 engineers, it's impossible for them all to be decent.
follow the money
employees will follow orders, orders are made by people who control the money
This is interesting as I had noticed this happening to me (in Chrome) when the anti-ad-blocking started. I assumed that it was YT's way of "annoying" me still while no ads were shown... It was eventually replaced with the "You cant use Adblockers modal" and now I just tolerate the ads.
So I wonder if that 5s delay has always been there.
When I ran into the adblocker-blocker (Firefox + uBlock Origin), I noticed that I could watch videos if logged out. So I just stayed logged out, and haven't seen an anti-adblock message since. Or an ad.
Added bonus, I'm less tempted to venture into the comments section...
Same, I use Firefox + uBlock Origin + YouTube Unhook for a cleaner interface. I also always watch videos on private navigation windows (my default way of browsing the internet) and I manage subscriptions with the RSS feed of the channels, much better to track what I have watched since the default homepage of YouTube does not display the last videos of your subscriptions.
Edit: I have forgotten to add sponsorblock to the list of extensions
1 reply →
One of the benefits of ublock origin for me is blocking the youtube comments section, along with all of the video overlay elements.
I'm using Firefox + uBlock Origin logged in and it works totally fine. Maybe Youtube removed the anti-adblocker on select accounts? I remember I once entertained myself with writing a report in which I sounded like I'm sitting in a retirement home and have no clue what's going on with "ad block." Did perhaps someone actually read this?
4 replies →
It's weird but I saw the anti-blocker modal a week or two but them it stopped appearing and never saw it since shrug
Might be because of the EU ruling, if you're in the EU.
1 reply →
Another way I noticed is good at skipping ads when adblocker fails is to refresh the page. When it loads again it does not play the ad.
It's still trivial to block ads, but the delay has recently started for me, after never happening before. So presumably a very intentional volley in the ongoing war to own your attention.
I still use adblockers perfectly fine on Youtube. There was never a real interruption in adblocking either. You just need ublock origin + bypass paywalls.
I think they only disabled adblockers to logged users probably because non logged users don't have to agree to terms of services.
2 replies →
ABP also still works just fine. I prefer the armsrace being taken care of someone else
Just install adblocker?
Or Freetube / Newpipe
1 reply →
Meh.. I could but I have to tolerate them on TV anyway. I may look to install pi-hole one day.
3 replies →
How is this not blatant anticompetitive behavior?
Capitalism as it exists is, at its core, anticompetitive.
This is happening to me in Chrome as well so I don't think it's tied to the browser you use.
Curiously it happens only on one profile, in another Chrome profile (which is also logged in to the same Google account) it does not happen. Both profiles run the code in your comment, but the one that does not have the delay does not wait for it to complete.
The only difference I spotted was that the profile that loads slowly does not include the #player-placeholder element in the initial HTML response. Maybe whether it sends it or not is tied to previous ad-blocker usage?
What does piss me off is that even if you clear cookies and local storage and turn off all extensions in both profiles it still somehow "knows" which profile is which, and I don't know how it's doing it.
Is the use of the "E" notation common in JS? I can see that it (could be) less bytes, obviously more efficient for bigger values... Looking at the script I can see it is minified or whatever we call that these days. I guess my question really is: did someone write "5E3" or did the minifier choose it?
(Sorry this is heading into the weeds, but I'm not really a web developer so maybe someone can tell me!)
Because 5E3 is shorter than 5000, just like you can often see !0 to get "true" in minimize code because it saves two characters.
In js I thought 1==true, and 1 is shorter than !0 ??
Never seen the use of exponential notation for numbers in js though (not a surprise, I'm not really a programmer), it seems sensible to me from the point of shifting the domain from ms to seconds.
3 replies →
I wonder if this actually decreases the byte over wire. 5000 compresses a lot better.... sorry for OT
Interesting question. Has anyone tested this?
Almost certainly the minimizer
Totally possible that the minifier did this, yes.
How/When does that script get loaded? It’s not showing up in my network tab. Videos also load instant as usual.
Trying to be charitable here: could this be a debug/test artefact that inadvertantly got into production?
Unlikely. Google has been breaking non-Chromium (or sometimes even just non-Google Chrome) browsers for years on YouTube and their other websites. It was especially egregious when MSFT was trying their own EdgeHTML/Trident-based Edge. Issues would go away by faking user-agent.
> It was especially egregious when MSFT was trying their own EdgeHTML/Trident-based Edge. Issues would go away by faking user-agent.
Why is there more than one user-agent? Does somebody still expect to receive different content based on the user-agent, and furthermore expect that the difference will be beneficial to them?
What was Microsoft trying to achieve by sending a non-Chrome user-agent?
6 replies →
> Trying to be charitable here [...]
There is no reason for charity with such a large power difference. For Firefox, "bugs" like this can really end up being a lost one-shot game.
It's like people walking by and casually reaching for your phone. It's always meant as a joke, unless you don't pull it away fast enough. Then suddenly it wasn't a joke - and your phone is gone.
This is not rooted in any reservation against Google in particular. If you are a mega-corporation with the power to casually crush competitors, you should really want to be held to a high standard. You do not want to be seen as the accidentally-fucking-others-up-occasionally kind of company.
Without studying the minified code I wouldn't assume malice just yet, this could be just an inexperienced developer trying to lazily fix some browser-specific bug, or something that accidentally made it to production like you say
You think they let inexperienced developers touch the YT code base without proper code review? Even if that were the case, which is an extremely charitable assumption, that itself would be malice in my opinion.
7 replies →
there is such a thing as overextending the benefit of the doubt, to the point that malicious actors will abuse it.
It could even just be a timeout as part of retry logic or similar. A lot of people seem to be saying that there is no reasonable reason to have a `sleep` in a production application. But there are many legitimate reasons to need to delay execution of some code for a while.
As the saying goes: "we like naked girls, not naked sleep". Even the interns should know that, naked sleep is just bad - not fixing anything.
If, with Youtube size, they do not test on Firefox, this is as much malice as doing this deliberately.