Did Google cripple Edge’s youtube performance?

Recently this article has been making the rounds on slashdot and other tech sites. The TL;DR of the article is a Microsoft intern insinuates that Google may have intentionally crippled Edge video rendering performance on youtube:

I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn’t keep up. For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome’s dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower.

My initial reaction to this wasn’t “gee, that’s suspicious…” but more along the lines of “wait a minute… I’m pretty sure I’ve written that exact code?”

I’m a video engineer who has written a video player from scratch, and I have independently positioned a blank div on top of our video element. Here’s source code for disbelievers (apologies in advance for the Angular):

<div class=”ie-idiot-shield noselect” ng-if=”customSkinSupported” ng-click=”togglePlayPause($event)”></div>

…

// IE has these insane keypress handlers that totally steal *everything*, and do hideous things to all of our logic.
// So far I’ve found no way to disable the player when it has focus. So we use this shield to overlay a faux window
// on top of IE to prevent anyone from actually selecting it.
.ie-idiot-shield {
position: absolute;
width: 100%;
height: 100%;
background: rgba(0,0,0,0.0);
z-index: 3;
}

Here’s the git commit message (8/2015):

Finally, a fix for IE’s insane keypress logic

By overlaying an unselectable transparent element on top of my video element, I can effectively prevent someone ever from selecting it, and this avoids a huge amount of keypress nightmare logic that currently exists. I’ll clean up the other hacky crap in the html5 lib in a bit, but this should make my life way easier.

Here’s an alternate hypothesis of what may have happened at google:

1. Some product manager in YouTube decided accessibility was a major initiative. Because, y’know, blind people.
2. They wanted to add standard keypress logic to their video player.
3. They quickly realized nope: <video/> has no such thing. (this subject probably warrants its own blog post; one major omission of the standard is, IMO, standardized accessibility across implementations)
4. They quickly realized some browsers are heinous and you want to block their keypress handlers entirely.
5. Some programmer found a workaround. The same one I did.
6. Some completely separate arm of the business decided to discuss battery life. We’re talking about a company with 85,000 employees here, so this is hardly far fetched.

Knowing this, here’s a few things to keep in mind:

1. The statement by the MSFT intern smacks of someone who too quickly attributes malice where no such accusation is appropriate.
2. A “state of the art” rendering engine? Well, apparently it isn’t “state of the art” enough to handle a blatantly obvious test case. It can’t handle something on top of it. That isn’t “state of the art.”
3. What precisely is wrong with positioning another HTML element on top of a video element? The whole point of the video element is: it’s a legit part of the DOM instead of some mangy <object> tag like we had prior to HTML5. It is 100% legit to put a blank div on top of the video element, or nearly any other element for that matter. Welcome to the web.
4. Why would the already dominant browser in the market go out of their way to cripple some minor player in the field? And to cripple them on a single video streaming site (what about netflix, hulu, prime, etc.)? And knowing full well that 95% of web users honestly don’t care? The argument doesn’t pass the smell test.

As a video engineer, I have to say this:

1. Edge’s WebRTC implementation sucks.
2. Edge’s video tag implementation is a confounding factor I won’t miss.
3. Edge lacks MediaRecorder, despite repeated requests to MSFT to implement. Ever implement a webassembly version of libvpx and libopus? I have. You know why? Edge.

Yeah, Chrome is a monoculture, but it’s like the entire collective hive mind of programmers is ignoring that it’s a monoculture for a reason. It’s a monoculture because consumers prefer it. If, as developers, we don’t want a monoculture, then our only option is: make a product consumers find more compelling.