Google's HTML 5 media player uses Media Source Extensions (MSE) now [1]. This enables them to use adaptive streaming implemented in JavaScript using DASH JS libraries.
Unfortunately MSE support is not complete in Firefox so the MSE using HTML5 YouTube player doesn't work. This will be why Google would be serving Flash. I don't know if they continue to serve the non-MSE HTML 5 player.
MSE support in Firefox is in progress. Nightly builds can enable it by changing the 'media.mediasource.enabled' about:config setting.
Don't do this though because it will definitely degrade your YouTube playing. Due to an incomplete feature it waits for the entire video to download before playing. There's a patch for this that gets playback working but there are still issues with the adaptive streaming itself (because the implementation is incomplete).
Follow bug 881512 [2] if you want to track support in Firefox for the "Get YouTube working with MSE" issue.
I wrote a bit about this [3] a while back and will do an updated post, if someone else doesn't first, once YouTube support is stable.
MSE is actually really cool and makes streaming media over HTTP much more pleasant. I'm not surprised they want to keep the number of codepaths they have to support low. As the GP mentioned, MSE is coming to Firefox soon anyway.
ActiveX is actually really cool and makes [whatever new feature] much more pleasant. I'm not surprised they want to keep the number of codepaths they have to support low. Have we been here before?
Hardly. The "new code/technology" is completely open spec/proposal and its implementation is open source in Chromium. In terms of "Google pushing it", the spec was co-edited by people from Microsoft and Netflix. In terms of "supported only by Chrome", this is strictly Mozilla's fault as there is nothing stopping them from implementing the spec today.
This article and a lot of comments here are really sensationalizing reality. Google needs to serve tons of video data efficiently so they are motivated to push things like MSE. Reading this as "Google crippling Firefox" seems really dramatic and contrived.
The author makes a massive leap of faith between "I downloaded the pages with Chrome and Firefox user agents, and there was differences" and "can't understand the differences, therefore there's obviously malicious intent".
Cross-browser development, especially for cutting-edge, novel features on a massive codebase is hard. Not insurmountably, but it doesn't allow one to automatically attribute it to malice.
Yes, he lost me completely there. I was expecting he would at least provide his data (the diff'ed portion) so more knowledgeable people could pitch in. Instead I got no data and a sweeping conclusion.
With this claim, you really need to figure out why and what. It's http and text, so figuring out what triggers the different behavior is feasible and needs to be done before throwing out allegations.
My guess is that it is probably not overtly malicious, but that people at Google are just responding to incentives. There are simply more incentives for Google to get things working 100% right in Chrome.
It is not to say that it is ok, though, as it could result in more people switching away from Firefox -- which is not a good thing for the web.
I, an enthusiast Firefox user, had to stop using Hangouts in Firefox because it could get excruciatingly slow (while fine in Chrome). Again, not saying it's Google's fault; it may be the case that with my configuration, Firefox is just generally slower than Chrome for the kind of fancy code that powers Hangouts. But they certainly did not try to make it run well for me, for lack of incentives. Many people (especially lay) would have responded by switching to Chrome. I responded by deactivating gmail chat and switching to Skype.
This is true about incentives, but it's also how pretty much all bad stuff in the real world actually happens, rather than black hatted evil-doers twirling their mustaches (though there's a bit of that too).
Some consider "incentives matter" to be a good two word summary of economics, it would be great if people bore that in mind when dealing with corporations, rather than treating them like local sports teams.
Though I think in this case, Firefox and Google actually have their incentives pretty well aligned, with each other and the general public (generally "make web video better"), it's just a matter of timing.
For me following these steps using Ubuntu I get the Flash player both times. Did you get a preroll ad both times you tried it? They use flash (except for the MSE player). If you didn't get a preroll you may have got the HTML 5 player.
I just noticed that if I switch to "https://", Flash-based videos are now served. Back to "http://", same video served HTML5. So this is it, "https" is the culprit (for whatever reason)?
So, could it be that Firefox somehow doesn't provide the proper cookie value telling the site to use HTML5 when using "https://" (I did set HTML5 pref with "https://")?
Edit: A cookie named "GED_PLAYLIST_ACTIVITY", used for "[e]ncrypted connections only", is used on Firefox only. I don't see this cookie on Chromium on an encrypted connection. So, there might be a link with the presence of this cookie and the serving of Flash-based videos.
I can confirm this is the behavior I'm seeing on Firefox. However, it's important to note that YouTube seems to force https if you're logged in, meaning logged-in Firefox users ALWAYS get the Flash player. I've resolved this for now by installing the YouTube ALL HTML5 add-on ( https://addons.mozilla.org/en-US/firefox/addon/youtube-all-h... ).
While I respect what the author is trying to do, it is a pretty huge leap to make such conclusions. This is the kind of thing you file a bug report for and get a response from a Google dev about the issue.... not start a potential browser flamewar without enough fact.... [especially if you say you saw a JS error but don't say what it was....]
So two features of a site run by Google are not working as expected on "third-party" software and the conclusion is, that Google is doing it with malicious intend? Thus could I conclude that if something at medium.com is not work properly on all browsers, they are trying to cripple that one browser?
To the author: Next time think a bit more critical about the topics you're writing.
Well, I had to test this. Using Firefox 28. Went to Youtube front page. Click top video available. Got served Flash-based video. Went to http://www.youtube.com/html5 to request HTML5 to be served. Went back to front page, clicked on top video. I was served a HTML5 video. Linux Mint 16/Cinnamon here.
Although I disagree with a lot of Google's policies (with respect to privacy, etc.), the claims made by the author here don't make much sense. It's pretty clear that the author and many of the people commenting don't understand how web development for multiple platforms works. Using a new web standard technology (http://www.w3.org/TR/media-source/) that isn't implemented by all browsers and providing a polyfill for non-compliant browsers isn't "crippling" the other browsers. It's considered best practice. If websites only used technologies that are available in all browsers, the web would never move forward.
Consistency in video support is almost non existent. So serving variations for every platform is frequently better simplified. Rather than come up with every possible test we simply broke it up into two categories, those that need flash (HDS) and those that don't (HLS). I'm sure there are some browsers that would work for HLS that are getting served HDS and flash, but they still work, and we got fairly wide compatibility without having to spend too much time maintaining compatibility lists. This might not be the best way to run a video specific site like youtube, but being a moving target, I wouldn't be surprised.
Am I missing something? I think that "I observe the same problem in Windows as in Linux" DOES allow rejection of the hypothesis "The problem is with Linux only".
S/He did in a way. S/He tested if the problem existed on other operating systems which makes a lot more sense then debugging your kernel at the first sign of trouble.
The best case here for example is a faulty signal from a control/logic board. Best to grab a second multi-meter before you start probing all over the board.
I can't quite put my finger on it, but whenever I access maps.google.com from Firefox running on my Arch Linux... I am unable to zoom or search or do anything. It just shows me the world.
When I open the same URL in chromium however, everything works perfectly.
Google is really the new monopoly. They've bundled a new non-standardized technology into the platform and then brow beat everyone else into implementing it by having the rest of the "planned economy" (aka Google Apps) use it.
Would it be so surprising? Google has been doing this for years to other browsers. Blocking based on UA, using features not supported by other browsers (and showing those features to those browsers), manipulating users to downlaod Chrome...
Firefox was just way too big piece of the income to poke it.
This is just FUD. Google has typically provided full functionality to all modern browsers — fallback versions being served to older UAs only. Typical advanced features Google uses are things like SPDY — this differs from the old-fashioned Microsoft embrace-extend-extinguish in that they are almost all standardised features, in a variety of stages of implementation among different browsers.
And users aren't "manipulated" into downloading Chrome - that's a weasel word.
There is also a debatably bad faith block on Microsoft's well-designed Youtube app on Windows Phone that it put out a while ago. This app failed to live up to some rather unreasonable demands from Google, so they banned the entire thing wholesale. (note that there are other Youtube apps on the Windows Phone store, such as Metrotube, which are not blocked)
Google isn't the "do not evil" white knight in shining armor it used to be. It is much closer to the old Microsoft these days.
In our last test, IE mobile still did not offer a good maps experience with no ability to pan or zoom and perform basic map functionality. As a result, we chose to continue to redirect IE mobile users to Google.com where they could at least make local searches. The Firefox mobile browser did offer a somewhat better user experience and that’s why there is no redirect for those users.
Frankly, a perfectly justifiable reason to perform a redirect.
There is also a debatably bad faith block on Microsoft's well-designed Youtube app on Windows Phone
Isn't this sorted? IIRC, this was down to Microsoft not complying with terms of use wrt. the implementation of ads.
Google isn't the "do not evil" white knight in shining armor it used to be. It is much closer to the old Microsoft these days.
Google are not, and never were, a "white knight" - they're just a better-than-average-at-openness tech company. If those examples are the worth you can highlight, then the comparison to Microsoft—who, if you remember, actively tried to eliminate Linux!—is beyond preposterous.
Frankly, a perfectly justifiable reason to perform a redirect.
I can't say with any certainty what things were like at the exact time of the block, but I just popped open Google Maps with a Windows Phone (which doesn't have most of the latest large updates, just some hotfixes from like 6+ months back) and pan, zoom, etc. all work just fine and is very smooth. And this is one of the earlier phones. On top of this, all they did was redirect back to google.com, without any message as to what was going on. (e.g.: your browser does not work well with Google Maps yet, you can do a local search from our main website for now) The whole thing just... smells kind of bad to me. Regardless of whatever statement they might have made.
Isn't this sorted? IIRC, this was down to Microsoft not complying with terms of use wrt. the implementation of ads.
I believe in the big kerfuffle that went on, Microsoft was basically saying "Work with us and we'll comply", but Google basically didn't give them any APIs or anything to work with in order to make a compliant app. (I think they even ended up finding some private APIs in order to make some stuff work) I think, in the end, the reason it got banned was down to some clause in their terms of use that required them to use web technology in their implementation, which would have horribly crippled the app, and was not particularly feasible to implement in any reasonable amount of time. Not because Microsoft refused to display ads.
Google are not, and never were, a "white knight" - they're just a better-than-average-at-openness tech company. If those examples are the worth you can highlight, then the comparison to Microsoft—who, if you remember, actively tried to eliminate Linux!—is beyond preposterous.
Unfortunately, I can't really give a good response to this. Part of what I might be able to say is private related to my job, and part of it is just a general feel for what the company is slowly turning into, rather than any specific enumerable list of things I can point to. There are things I can point to, such as how they handle Youtube and the content creators on it, or how they handle dealing with Microsoft, or customer support, the automated systems which hurt those that provide value for Google, etc., but I don't think any of it can live up to the level of "tried to kill Linux" that Microsoft was at a while ago. But I think that they might be starting to head in that direction, and that a lot of people who actually view them as a sort of "white knight" (see lots of comments on HN for examples of that when it comes to Google, or news, etc.) will gladly welcome that.
I guess I did have a few things to say in response. Agree or disagree with me as you will, this is entirely my own opinion.
I think, in the end, the reason it got banned was down to some clause in their terms of use that required them to use web technology in their implementation, which would have horribly crippled the app, and was not particularly feasible to implement in any reasonable amount of time. Not because Microsoft refused to display ads.
There are already public APIs for building a full fledged Youtube client:
The issue was that Windows Phone 7 & 8 webview didnt support inline video playback, so they couldn't use the public playback API so were asking for access to Google's private APIs. Google declined
Opera used to be routinely blocked on Google properties years ago - Google Adwords as well as Google Analytics. There was no fallback, just a block message. When you changed the user agent, the site worked ok.
I'm not sure about today, but it was definitely a real thing.
Background image on Google search was blocked by UA, search by image was blocked by UA. Gmail, google homapge and youtube all showed message convincing user that they should switch to Chrome. Various applications used features not supported by all major browsers.
Well, uglier featurephone-like webpage, no swiping menu from left, no card-like results display, etc. Now it's better than months ago but still quite a different experience than stock android browser or chrome.
Maybe it's me being naive and not tech-savvy but I used to think one page should look the same on different browsers.
Unfortunately MSE support is not complete in Firefox so the MSE using HTML5 YouTube player doesn't work. This will be why Google would be serving Flash. I don't know if they continue to serve the non-MSE HTML 5 player.
MSE support in Firefox is in progress. Nightly builds can enable it by changing the 'media.mediasource.enabled' about:config setting.
Don't do this though because it will definitely degrade your YouTube playing. Due to an incomplete feature it waits for the entire video to download before playing. There's a patch for this that gets playback working but there are still issues with the adaptive streaming itself (because the implementation is incomplete).
Follow bug 881512 [2] if you want to track support in Firefox for the "Get YouTube working with MSE" issue.
I wrote a bit about this [3] a while back and will do an updated post, if someone else doesn't first, once YouTube support is stable.
[1] http://www.w3.org/TR/media-source [2] https://bugzilla.mozilla.org/show_bug.cgi?id=881512 [3] http://bluishcoder.co.nz/2013/08/20/progress-towards-media-s...