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.
Oh, and they also falsely show "4K" in the video quality icon, but "accidentally" play a 720p or even worse quality stream. If you manually select the 4K stream quality, then and only then will YouTube deign to show 4K to you.
Something related to this which I find extremely frustrating is that I'm capable of watching a 4k video in my browser just fine. So if I decide to buy or rent a movie on youtube, they can only be played back at 420p.
Apparently this is due to DRM restrictions, but the frustrating part is that you can pay extra money for the HD version and there's nothing telling you about this not being supported in your browser until you've made the purchase (by just allowing 420p and needing to search for why it's broken)
That has irked me for quite some time. I always manually select 1080p, because sometimes YT claims it's already playing 1080p, but it's obviously not and the video starts buffering anew when I select 1080p manually. Quite annoying
I haven't see this other than for brief periods during quality switching (it seems to play out the current buffer in lower quality but new chunks are downloaded at the displayed target quality). However for some reason it does often just load at a very low (sub-720p) resolution and I need to manually up the quality or it will never get to the highest quality (I'm watching on a 4k monitor with great internet and hardware decoding, 4k has never stuttered for me).
I have personally noticed this many times. I’d blink and wonder if it was just my eyes going bad but nope, soon as I select HD quality manually I can read text again.
I have a hard time believing that's actually what's happening. If they wanted to slow down other browsers, why would they choose this easily discoverable way? They could have easily slowed down serving of JS files (and other assets) based on the user agent to a similar effect. It seems more likely this is just a debug snippet that has made it into production by accident.
Seems odd to do something so brazen while also publishing information that (could) prove intent.
Google also modifies how business information can be accessed from Firefox Mobile. You can't read reviews easily from Firefox Mobile. At least not my install.
That's because it's not actually what's happening. I'm all for bashing bigcorps and especially ad empires but reddit folks confused correlation with causation here.
The code in question is part of a function that injects a video ad (that plays before the start) and the code itself is just a fallback in case it fails to load over 5 seconds so that video page doesn't break completely.
Why was this affected by user agent change? My best guess is that on some combinations they somehow decide not to show any ads at all (for now) and therefore this function is not called and some other code path is taken. This is consistent with my own experience with the recent anti-adblock bullshit they implemented. The banner was not being shown after user agent change implying it's one of the considered variables.
You can verify all this if you click 'format code' in browser debugger.
I use Firefox, and Google's sites are literally the only ones where I consistently have issues. There was a period of about a month this summer where Google Maps was just completely broken for me, the map wouldn't update at all when attempting to search or pan. There was recently a several day span where chat in Gmail had a 10+ second input lag due to some font-related JavaScript code spinning the CPU nonstop. It's literally gotten to the point where I keep a Chrome window open and use it exclusively for Gmail, Google Meet, YouTube, and Google Maps.
It's pretty obvious from the outside that supporting Firefox is not a product priority for Google. It also seems clear that it's in their best interest to have users choose Chrome over Firefox. My guess is that this likely emerges from a lot of very reasonable sounding local decisions, like "prioritize testing on browsers with the most market share," but it is convenient how those align with the anti-competitive incentives.
You're basically looking at testing being done on Chrome (because it is Google's, and because of its large market share), Safari (because it runs on a large percentage of completely exclusive platforms where the customer can't switch, and because of its large market share), and Edge (because there are still many corporations that do "Nobody ever got fired for choosing Microsoft" and lock down browser options to just Microsoft's offering).
At this point, Firefox is very much an also-ran on two axes: market share is tiny and nobody forces it on their captive audiences. We may as well ask why Google isn't optimizing testing on Opera, or Samsung Internet.
(There is also the issue of under-the-hood engine. Since so many browsers have converged on a few core and JS stacks, testing on one exemplar of that stack has a tendency to suss out bugs in the other stacks. Firefox still being its own special snowflake in terms of JS engine and core means it has more opportunities to be different, for good or for ill. So there's a force-multiplier testing the other browsers that one lacks testing Firefox).
I had the same Gmaps issue, I disabled LocalCDN for the site and panning etc worked again. Apparently the addon must be fixed to account for whatever they were doing.
I use Firefox across Windows, Mac, OpenBSD, and Ubuntu. I've not seen any specific issues with Google sites at all. I only really use Docs, Maps, and Youtube with any regularity but I've not really seen any of these issues.
It's clear Google is only testing for chrome engine and safari: which comprise 97% of the browsers being used. Would you increase your testing by 50% to thoroughly test for 3% of the market?
The most interesting part from the discussion was noting it's implemented in the most basic, easily avoidable way (just spoof chrome) implying engineers unhappy with these tasks.
I sometimes wonder if the use of Firefox is under reported just because a lot of it's users are power users, installing extensions that spoof the user agent. I know I did for a long while, making my Firefox pretend it was Chrome on a Windows machine.
Or potentially a concurrency bug trigger? "One in 1000 times X takes a bit too long and causes problem Y; I'll make X take minimum 5 seconds so I can trigger Y reliably." Then fixes Y but forgets to remove the delay.
Such fix won't sleep for 5000 ms though. In my reading it looks like a part of the adblocker detection code. (EDIT: Relocated the actual analysis to https://news.ycombinator.com/item?id=38346602 for more visibility.)
Code generally does not enter the YouTube code base without a lot of review namely (1) performance tests and (2) code reviews from multiple teams. Lines like this almost certainly get flagged/increased scrutiny. It would be very hard to imagine multiple people didn’t know about this and assign the blame to a single person.
As a JavaScript Dev, around 2010-2012 it was not uncommon to see `setTimeout(..., n)` hacks, often with n=0 but sometimes even n=1000, n=5000 into a codebase. This could workaround some bugs, and given the overall low-quality state of the JS ecosystem back then, often a last-resort.
And yes, am guilty too of committing this to prod back then. I think I haven't had a case where this was deployed in the last decade, but in the ugly SPA days pre angular v1 (and even during angular v1), where you code was this big glued-together conglomerate of various 3rd party UI libraries, this was common. Its ugly as hell, and you really had to be there at that time to understand this. But often it was just a cheap alternative, while debugging and fixing the truly underlying cause would be several man-days or even weeks.
My point being: It might have slipped their QA cracks and was at some point intended to workaround a bug of some obscure Firefox behavior. For a company at youtube's scale this is however pretty embarrassing.
Oh, I noticed this yesterday and assumed it was ad blocker hostility. Which I guess it may well be -- are Firefox users more likely to use ad blockers? Possibly. Certainly on Android. That doesn't strictly matter though, presumably the Youtube people try to avoid stepping on the Chrome people's toes.
Given Google is apparently going ahead with killing extensions on Chrome it's not hard to imagine some scheme where a guy is just lookin' at'cha merchandise and happens to be carryin' a baseball bat is all -- you can't really blame him for some spillage, right? (make using Firefox painful to try and push people to Chrome). Before crippling Chrome? Sounds ridiculous, but one can't help but wonder...
Thinking about some more, the point could actually be to make users question if its because they have an ad blocker not even actively blocking anything, but simply installed. Some number of users may uninstall their ad blocking extension to see if it makes the lag go away.
I'm getting such a pause also in Chrome since a few days, I was assuming that it's fallout from the adblocking wars though (I use uBlock Origin and don't get the nag screen anymore since around the time that pause appeared)
On a completely related note, the UK's Competitions and Markets Authority has recently been flexing its muscles on digital markets. You may wish to know of this URL, specifically for reporting anti-competitive practices: https://www.gov.uk/guidance/tell-the-cma-about-a-competition...
This just... isn't happening for me? My only extensions are UBo, Return Youtube Dislike and Sponsorblock, so I presume a UBo filter is either fixing it or the change isn't rolled out to all users yet.
Using a browser devtools performance profiler could confirm this. I highly doubt there's a 5 second setTimeout in youtube. More likely switching of browser technologies based on user agent.
I would need to see a Firefox UA warm cache reload in the same video before I put any stock in this. This aligns to perfectly with the “But Google evil” narrative for me to believe it uncritically. Alas, I don’t trust the internet anymore.
[+] [-] ayhanfuat|2 years ago|reply
> 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...
[+] [-] lifthrasiir|2 years ago|reply
[+] [-] blueflow|2 years ago|reply
[+] [-] denkmoon|2 years ago|reply
Any idea what specifically causes it to happen, rather than just "firefox"?
[+] [-] jeroenhd|2 years ago|reply
[+] [-] Hamuko|2 years ago|reply
Although I just tried opening two videos and both opened basically instantly.
[+] [-] jiggawatts|2 years ago|reply
[+] [-] CapsAdmin|2 years ago|reply
Apparently this is due to DRM restrictions, but the frustrating part is that you can pay extra money for the HD version and there's nothing telling you about this not being supported in your browser until you've made the purchase (by just allowing 420p and needing to search for why it's broken)
see https://www.reddit.com/r/youtube/comments/pm0eqh/why_are_my_...
[+] [-] TheLML|2 years ago|reply
[+] [-] Voultapher|2 years ago|reply
[+] [-] kevincox|2 years ago|reply
[+] [-] vGPU|2 years ago|reply
[+] [-] rsolva|2 years ago|reply
[+] [-] conradfr|2 years ago|reply
[+] [-] BlueTemplar|2 years ago|reply
[+] [-] frankjr|2 years ago|reply
[+] [-] iinnPP|2 years ago|reply
Seems odd to do something so brazen while also publishing information that (could) prove intent.
Google also modifies how business information can be accessed from Firefox Mobile. You can't read reviews easily from Firefox Mobile. At least not my install.
[+] [-] gear54rus|2 years ago|reply
The code in question is part of a function that injects a video ad (that plays before the start) and the code itself is just a fallback in case it fails to load over 5 seconds so that video page doesn't break completely.
Why was this affected by user agent change? My best guess is that on some combinations they somehow decide not to show any ads at all (for now) and therefore this function is not called and some other code path is taken. This is consistent with my own experience with the recent anti-adblock bullshit they implemented. The banner was not being shown after user agent change implying it's one of the considered variables.
You can verify all this if you click 'format code' in browser debugger.
[+] [-] foob|2 years ago|reply
It's pretty obvious from the outside that supporting Firefox is not a product priority for Google. It also seems clear that it's in their best interest to have users choose Chrome over Firefox. My guess is that this likely emerges from a lot of very reasonable sounding local decisions, like "prioritize testing on browsers with the most market share," but it is convenient how those align with the anti-competitive incentives.
[+] [-] vmfunction|2 years ago|reply
[+] [-] MSFT_Edging|2 years ago|reply
There's 100% targeted de-optimization for firefox users and the burden of finding it is on the users it seems.
[+] [-] orbisvicis|2 years ago|reply
[+] [-] shadowgovt|2 years ago|reply
At this point, Firefox is very much an also-ran on two axes: market share is tiny and nobody forces it on their captive audiences. We may as well ask why Google isn't optimizing testing on Opera, or Samsung Internet.
(There is also the issue of under-the-hood engine. Since so many browsers have converged on a few core and JS stacks, testing on one exemplar of that stack has a tendency to suss out bugs in the other stacks. Firefox still being its own special snowflake in terms of JS engine and core means it has more opportunities to be different, for good or for ill. So there's a force-multiplier testing the other browsers that one lacks testing Firefox).
[+] [-] hospitalJail|2 years ago|reply
Need to call out them.
I'm basically forced to use Chromium on Linux.
[+] [-] 1980phipsi|2 years ago|reply
[+] [-] joelanman|2 years ago|reply
[+] [-] ikidd|2 years ago|reply
[+] [-] spicykraken|2 years ago|reply
[+] [-] whalesalad|2 years ago|reply
[+] [-] waveBidder|2 years ago|reply
[+] [-] taylodl|2 years ago|reply
[+] [-] mighmi|2 years ago|reply
@dang or op, wrong link. Should be: https://old.reddit.com/r/youtube/comments/17z8hsz/youtube_ha...
[+] [-] rsolva|2 years ago|reply
[+] [-] bad_user|2 years ago|reply
> setTimeout(function() { c(); a.resolve(1) }, 5E3);
The code looks like a silly concurrency bug fix, i.e., a lazy way to force ordering.
[+] [-] petargyurov|2 years ago|reply
[+] [-] gwd|2 years ago|reply
[+] [-] seydor|2 years ago|reply
[+] [-] lifthrasiir|2 years ago|reply
[+] [-] manjalyc|2 years ago|reply
[+] [-] welzel|2 years ago|reply
It will be a party for the EU to punish Google with an anti-monopoly lawsuit.
Best case: google gets forced to split up chrome, youtube and search as they obviously abuse their power.
[+] [-] littlecranky67|2 years ago|reply
And yes, am guilty too of committing this to prod back then. I think I haven't had a case where this was deployed in the last decade, but in the ugly SPA days pre angular v1 (and even during angular v1), where you code was this big glued-together conglomerate of various 3rd party UI libraries, this was common. Its ugly as hell, and you really had to be there at that time to understand this. But often it was just a cheap alternative, while debugging and fixing the truly underlying cause would be several man-days or even weeks.
My point being: It might have slipped their QA cracks and was at some point intended to workaround a bug of some obscure Firefox behavior. For a company at youtube's scale this is however pretty embarrassing.
[+] [-] asylteltine|2 years ago|reply
As opposed to now?
[+] [-] qwery|2 years ago|reply
Given Google is apparently going ahead with killing extensions on Chrome it's not hard to imagine some scheme where a guy is just lookin' at'cha merchandise and happens to be carryin' a baseball bat is all -- you can't really blame him for some spillage, right? (make using Firefox painful to try and push people to Chrome). Before crippling Chrome? Sounds ridiculous, but one can't help but wonder...
Thinking about some more, the point could actually be to make users question if its because they have an ad blocker not even actively blocking anything, but simply installed. Some number of users may uninstall their ad blocking extension to see if it makes the lag go away.
[+] [-] flohofwoe|2 years ago|reply
[+] [-] invalidusernam3|2 years ago|reply
[+] [-] azalemeth|2 years ago|reply
[+] [-] nan60|2 years ago|reply
[+] [-] etoxin|2 years ago|reply
[+] [-] insanitybit|2 years ago|reply
[+] [-] arzig|2 years ago|reply