Live data from Hacker News

Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

thurrott.com

181–190 of 207 posts

Re: Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

#181
post #173

Earlier quoted context omitted.

The change in useragent would indicate that if they didn't Add specifically to exclude it, it should detect as Chrome.

It sends 3 different useragents in different circumstances for some reason. Edg, Edge, and Chrome. This case is definitely the Edge team's fault.

The circumstances are domain-specific and it's been clear from the beginning that "Edgium" has (consistently) only been sending `Edg` to youtube.com from the beginning of the public release. Since the site in question's behavior changed, it likely wasn't the Edge team's fault.

Re: Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

#182
post #152

Of course this is all an accident and Google will later promise to change their workflow to ensure it never happens again (until next week).

At what point does a company consistently make enough "mistakes" that you just take them at their word that they are incompetent and stop trusting them?

Re: Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

#183
post #35

Earlier quoted context omitted.

Literally every Google website tries to get me to download Chrome whenever I use firefox or ie. Every. Single. Time. 2 attempts from Microsoft... not so bad.

I agree that two attempts isn't so bad. I think most users are upset because the notifications happened a lot more frequently in the past and using notifications from the OS for ads comes across as pretty slimy (because you only expect the OS to tell you when something important happens).

iOS, at least, sends just as many "Tips" notifications that also border on being ads for Apple and trusted third party applications, and I've never seen anyone near as harshly complain about "ads in iOS".

Re: Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

#185
post #55
post #45

Earlier quoted context omitted.

Technical correction. Edge had its own engine: Spartan > The Spartan rendering engine (edgehtml.dll) is a new component and separate from Trident (mshtml.dll). The new engine began as a fork of Trident, but has since diverged rapidly over the past many months, similar to how several other browser engines have started as forks prior to diverging. The new rendering engine is also being built with a very different set o…

Thank god they forked it. Parts of Trident were older than unit testing was a best practice. The cultural best thing to do was wall off those parts and never touch them because regressions would be impossible to find. I once did a bug fix for an assertion in the Trident. It’s still one of the hardest bugs I’ve ever solved. It was hundreds of stack frames deep in recursion (DOM layout code) in a function that was seve…

Double checked and the windbg feature I alluded to is now publicly available. Time travel debugging allowed me to pop the assert and then reverse the program state to eventually find when things started to go wrong. If you’re a windows developer and haven’t yet tried out this feature I strongly recommend it.

Re: Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

#186

Earlier quoted context omitted.

Disclaimer: I work at Google but not on YouTube, also speaking just personally. This isn’t practical at all in a latency sensitive environment. Feature detection works once JavaScript has loaded on the page, which means we either have to serve you a giant bundle of stuff you may not be able to use, or we have to degrade the experience of the latest browsers by detecting features and fetching more HTML/CSS/JavaScript…

> Feature detection stops being better when a) your supported browser list stretches into the early 2000s around the world and b) you are in a latency sensitive environment where it is unacceptable to degrade performance of the latest browsers. So whitelist “safe browsers” with server side user-agent sniffing and send the rest a bigger bundle with feature detection. There is no reason not to serve users of modern bro…

This works great until browser vendors that aren't whitelisted but support the features of a whitelisted browser (e.g. Chromium derivatives) realize that they're paying extra costs they don't have to, and change their user agents to a whitelisted browser...

Posted from Chrome-

> Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

Re: Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

#187

Earlier quoted context omitted.

If you think about it, that’s kinda what is happening, except instead of a punishing first load that appears broken and slow every time the user loses the cookie or we change our feature detection code, we do that ahead of time and the “cookie” is in a map where the key is the UA

Interesting, so to be clear, the sequence looks like this: 1. User goes to website, UA communicates previously known features for this browser. 2. Browser does feature detection after load 3. Browser communicates any new browser features up to a backend service, crowd analysis determines if new features have been implemented for this UA. If that's the case, that's a pretty awesome way of keying features, but I'd have…

No, I haven’t seen anything that fancy. The “user” in step 1 is internal QA testing the site on the browser, maybe after seeing it a lot in logs. Exposing users to novel UA strings to a bunch of feature detection JavaScript is an interesting idea but it’s probably better to log them and then do this in a QA setting.

Re: Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

#188

Earlier quoted context omitted.

>> It might sound naive, but why would fetching more JS later degrade the experience? I thought that bundle splitting was an accepted good practice. For example, you have your main core bundle, then some polyfill bundles (that get downloaded if the feature detector says it is needed), and then you have separate bundles for obscure and not-that-often-used stuff that gets loaded on demand. It is a genuine question, and…

> If the initial bundle isn’t enough to make the page useful, then the user has to wait for two requests to complete serially before they can perform their task. Since the alternative is just broken, I'm sure users with non-Google browsers would prefer a working page with one round-trip of extra latency. Meanwhile, it causes Chrome users no harm, they are unaffected. But anyway, there's no need for extra delay. You c…

To be clear, I have no insight into the specific topic of the article (and I probably can’t comment on it if I did). I’m simply defending the process of segmenting experiences by user agent, which the original comment suggested could have been the cause, and also suggested that it was never best practice to do so. I think I’ve made a pretty good case that the original response from the server ought to be informed by the user agent string in an environment like YouTube, mainly for latency reasons.

As for whether or not this particular issue is best solved by whitelisting and testing the new edge UA for this experience, or adding feature detection and testing that behavior with the new edge, isn’t really the same topic. And if this is what is happening, I’m not sure this method is “broken” here, it’s serving a working page to users with a preview browser.

Re: Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

#189

Earlier quoted context omitted.

I agree there are just a bunch of trade offs, and this shows you can’t please everyone. If you ship large bundles of polyfills people are sad they get some slow JavaScript, and if you give them fallback html and JavaScript that renders quick and supports their feature set, they are sad they didn’t get the same feature set as chrome latest. You have to minimize the fallback sadness as well as keep pushing better and b…

No, this shows you're not interested in pleasing anyone . There is no universe in which instructing the user to change browser software is preferable to adding milliseconds of latency at pageload. This attitude is so wrong it's almost sinister.

I am not defending YouTube redirecting a UA it hadn’t seen to download chrome when that UA explicitly went to /new for the new experience. I don’t know what happened there, and if I did I probably couldn’t say.

I am defending using the UA to tier responses based on the principle that it lowers the latency before the page is useful to the user, and I don’t see how that is a sinister practice.

Re: Google Now Forces Edge Preview Users to Use Chrome for the Modern YouTube

#190

Earlier quoted context omitted.

That's a very different product. Gmail basically never needs to refresh the page - you go through that loading bar once in the morning and there's no real reason to see it again the rest of the day. Every action in Gmail other than certain preference changes happen in the same page. YouTube is reloading the page on almost every action you take. Latency is a completely different priority there.

> YouTube is reloading the page on almost every action you take. Correct me if I'm wrong, but I was pretty sure that Youtube was a Single Page Application. A while back I wrote some user scripts for it that were heavily reliant on MutationObserver because it was the only way I could detect page navigation.

Youtube build spfjs for loading a page in "Structured Page Fragments" https://youtube.github.io/spfjs/
Post reply on HN