Do you think it would take 2 weeks or less than a hour if the browser affected was Google Chrome?
Google has systematically made Firefox an inferior option when using Youtube, pushing people to install Chrome instead because "Firefox doesn't work". At some point you almost start thinking they're doing it intentionally and maliciously to push their own (closed, DRMed) browser.
A few years ago Chrome gained majority among web developers and everyone just stopped testing with Firefox or any other browser. In fact not just testing - they started developing for Chrome only. And now we've got us into another IE6 situation and I think it will be even harder to overcome this time.
I use firefox on android as it is the only one that has extensions. I use uBlock and mht extensions.
On linux desktop too firefox is used mostly as it uses less memory than chrome when you have too many tabs open
I'm adblocking with AdAway on the device I rooted and with Adblock Plus (a local proxy) on the one I didn't root.
You get them on F-Droid.
https://f-droid.org/repository/browse/?fdid=org.adaway https://f-droid.org/repository/browse/?fdid=org.adblockplus....
I just checked too and Firefox looks different in the comments and it has been broken since the beginning of the mobile changes.
The comments on FF for Android do not have any additional indentation to suggest they are children. On firefox every comment takes the entire width of the screen, even if it's a heavily nested reply. On chrome comments have additional space on the left side indicating if they are children and who they are replying to.
The frontpage looks fine on Firefox. The comments do not look fine. When you view a stories comments on Firefox for android it's impossible to tell what comments are children.
> The comments on FF for Android do not have any additional indentation to suggest they are children.
I reinstalled FF on my phone and you're right. On my tablet FF behaves like Chrome. Some media queries gone awries or some FF quirk on smaller screens? FF-desktop behaves like the one on the phone when the window is resized to be narrow so it seems to be consistent with itself.
HN is using a media query to set the indentation using an empty image and setting its width. Check the /news.css file. Each comment is a tr, with 3 td elements. The image is the first one, then the votes arrows and the text. FF arranges those td in vertical, blink keeps them on the same row.
Digging into the CSS I realized that it's because of the display: block at line 88. If I remove it FF indents the comments. Opera keeps looking good.
The CSS is clearly setting these to display:block, so they should in fact stack. But the page is also in quirks mode (no doctype), and in quirks mode Chrome (and WebKit) seems to compute the display of <td> to "table-cell" no matter what the styles say.
So yeah, someone just wrote CSS that depends on a bug in Chrome/WebKit and either didn't bother to test in other browsers or doesn't care whether it works there.
Edit: https://code.google.com/p/chromium/issues/detail?id=369979 is the 1.5-year-old bug report on Chrome to remove this unnecessary quirk. Let's see what HN does if/when the Chrome folks fix that one...
Btw this could prove my point that people ditch browsers because of bugs of sites, if those sites look good in other browsers.
Many eyes/brains on the bug means quickly figuring out issues. If it was open source the patch for this would probably be in testing now.
Active and very Awesome community!!
I'm ashamed to say that this fix was on our list for a month and we hadn't gotten to it despite how easy it turned out to be (assuming, at least, that nothing breaks in other browsers). Fortunately HN has excellent users.
Thank you for caring enough to look into this!
Would be absolutely awesome if we could find somebody from HN to fix it.
Does it look the same on Chrome, with no indentation for comments and replies? I've removed Chrome so I'm unable to test but I thought this was just a bug.
I guess i should have seen it coming when they were gushing about their "coast" concept.
(I wrote the initial version of Firefox for Android's scrolling code.)
Just wish Vivaldi had gone mobile first...
On desktop, at least, you can fix this by making your browser window wider (just resize the window: you'll find a threshold past which the hierarchy appears or disappears).
That doesn't help much for mobile, where you can't really resize windows.
Gmail itself is unusable on Android + Firefox. When using an alternative browser you'll also stumble in problems with plenty of Android apps: Slack, Citymapper, etc... (when opening a web page intent, they expect that the only app that'll receive that will be Chrome)
The situation isn't as bad for desktop browsers, but it's depressing how things can still be broken.
Don't worry, it will get worse. Firefox is now forced to accept `-webkit-` in css (http://www.theregister.co.uk/2016/01/04/firefox_webkit_css_s...) not to be "broken". This will obviously lead to even less Firefox testing.
Hell, even I (my team) am contributing to this! We're working on Angular-based web SPA now. It hasn't got much functionality yet, but already has quite a few bugs when viewed in Firefox. And the usual answer from frontend guys is "It's a firefox bug!".
Aside/Rant: I also get the impression that frontend devs have never read the CSS2.1 spec or bothered to understand it (CSS3 is longer, and consists largely of special-purpose extra modules, so a complete reading is less valuable and more difficult). There's somehow this feeling that since CSS "isn't a real programming language" you should be able to use it intuitively. And when things don't work out and you fiddle until it works without giving thought to why, that's OK. That's such a huge waste of time. The box model may not be 100% intuitive, but boy, if that's your standard, what you doing in IT?
It's no harder to only test on Chrome in Linux and IE in Windows, I fail to see how that's an excuse. The only excuses are IE testing when developing on OSX and Safari testing when developing on Windows, it's trivial to install both Firefox and Chrome on any OS.
There are a certain kind of app on Android that makes the device FS available via a web browser.
Thing is that these apps invariably makes use of a Chrome-ism when dealing with drag and drop.
In Firefox you can only drag a single file at a time. drag over multiple, or a folder, and there won't be much of a result.
In Chrome however it will transfer over just fine.
This has been sitting in the Mozilla bugtracker for some time, because the Chrome behavior goes beyond the HTML spec for file uploads.
Certainly it could save developers a lot of works and save users a lot of time, but it may become next ActiveXObject("Microsoft.XMLHTTP");
Maybe Chrome should put a warning into the console, saying that this function is experimental.
Dang - have you seen HN in Firefox on Android recently? Is there something we can do to improve this? Given that HN receives a moderate amount of (visible) changes recently, is there a way to make the site work in that situation/setup?
To elaborate it further, the problem common to every browser I tried (the only one missing is Safari) is that comments are nested and if I zoom the page to be actually able to read the text, I have to pain points now:
1) I have to keep scrolling right and left to keep them in view as I scroll vertically to follow the threads.
2) Even if 1 were not bad enough, the comments are too wide now to fit into the screen (remember that I zoomed in) and I have to horizontally scroll at each line. The only browser not to suffer from that is Opera which reflows text after a zoom (if you enable that option). I'm left with problem 1 but it's the least painful.
I suspect that a div layout would fare better, still there are tons of blogs with div layouts that end up with 10px wide comments at deep nesting levels. Maybe some media queries to remove nesting for devices not wide enough and adapt the page width after a zoom? I don't even know if the latter is possible.
Edit: I checked on the desktop and it seems that you already reduce nesting when the screen width is reduced, to the point of removing it at all. I wonder why my tablet and my browser are not affected and keep displaying the indentation to the left. Any browser, any user agent (desktop or mobile). They're 1600x2560px and 480x800px.
They said "It's a bad bug and we're going to fix it". So I'm waiting.
The indentation for one. Notice that the second comment is an answer to the first, but is on the same level of indentation. Following discussions like that is highly annoying.
Weird: While grabbing the phone to answer your question I noticed that "threads", i.e. the view of my comments, works fine. Just the comments below submission links are broken.
Compare to Chrome: http://m.imgur.com/Wpusprq
Note that I do use uBlock in Firefox. Now that I think about it, that might be relevant as well. But then again, why would that break the submission view and not the "threads" link?
(1) Lines are not terminated at the screen boundary on the tablet if I zoom in. They keep going off screen to the right. Same on the stock browser on the phone and with Opera if I turn off text reflow.
I hate to defend Chrome, but I don't think that comparing Chrome to IE6 is warranted (yet). The problem with IE was that a large number of users were stuck with IE6 and never updated (either by their own choice or their IT departments'). So web developers had to write code for modern web browsers, and then implement a compatibility layer (I guess we call it polyfill, these days) for IE6. Chrome, however, has an update mechanism that the vast majority of users and IT departments do not override. Chrome is not in an IE6 situation because historically the number of users running old versions of Chrome is small and drops off rapidly as new versions come out.
I pulled these graphs from a few years ago, comparing Chrome adoption to IE adoption:
http://cdn.arstechnica.net/wp-content/uploads/2012/10/chrome...
http://cdn.arstechnica.net/wp-content/uploads/2012/10/intern...
Notice that Chrome uptake is very rapid, with the vast majority of users being on the current version of Chrome after approximately two to three months. Compare that with IE, where the majority of users still aren't using the most modern version of Internet Explorer after two to three years.
So no, I don't think Chrome is in the same position as IE. Google pushes updates to Chrome on a frequent basis, and, more importantly, those updates are actually applied by users. That said, it's still possible that Google could tomorrow do what Microsoft did when IE "won the browser war", which is disband the team and cease Chrome development. Do I think this is a likely scenario? Of course not. Is it possible? Sure.
And then every browser had to either 1. be "broken" because the web-pages didn't work, or 2. forego W3C, standard-process and all that and emulate IE's bugs in order to be "real" browsers people could use.
And long after IE6 is gone, all that is still hanging around, causing issues to this day.
Right now we're getting a Chrome monoculture. People are using pre-standard Chrome and Webkit only features in production websites. In the future those websites will stick around, no matter if Chrome users update their browsers or not.
Chrome is the new IE. With Google giving a shit about real standardization, launching non-standard features in Chrome and production websites at the same time, they are the new Microsoft.
Are there any features they are pushing in Chrome they are simultaneously not pushing on w3c to adopt? The problem with IE6 is that it not only did its own thing, it did the opposite thing the standard said to do. If Chrome is just standard + new stuff, and that new stuff eventually becomes standard, it isn't a problem. But its standard + new stuff + anti-standard bullshit, the latter is the issue and Google should be criticized for it.
Web standards seem, from where I'm standing, to be very post-hoc.
Indeed, I think that's the way it ought to be. How many times has it worked out well when you've fully specified something, before you attempt to actually build it? For me that number is very close to 0.
I think this is a much better practice than a bunch of dudes just deciding what browsers will support and how they support it without actually trying it on first.
It's pretty much all in the open. No need for conspiracy theories. The environment is significantly different than it was during the early IE days.
The non-updating users problem is a bit different. I guess it had quite a contribution to the problem discussed above (e.g. if Microsoft had a good mechanism to switch most of IE6 users to 7, they might have made 7 a better - less "compatible" - browser).
And Chrome's great upgrade mechanism is one of the reasons I think the Chrome situation will be even harder to overcome. IE6 became so old and ridiculously bad that some sites stopped providing first-class user experience to it's users, so that users had to do something - upgrade. The same think won't probably happen to Chrome, because:
1. Google probably remembers Microsoft's history and will try to avoid the same mistakes.
2. They have an automated mechanism to keep Chrome updated.
And as long as they keep gmail and facebook working great in Chrome (and - ideally - worse in every other browser), they are safe.
I guess this is even good for the users - uniformly good user experience on all devices. Though - of course - if you don't mind exposing every detail of your online life to Google. http://uncyclopedia.wikia.com/wiki/Nobody_cares
End result is that the last version that shipped on XP became the lowest common denominator.
You have a lot of new stuff being designed & tested using Chrome, with some site breakage if using Firefox. Similar to several years ago when releasing sites that "work best with Firefox" (complete with badge images stating such), leaving IE6 users with a lesser experience.
Also, aren't most the Chrome-specific things disabled unless the app runs as an extension to discourage this type of chrome-only behaviour? I can't test/verify now, since I'm on my phone. This excludes CSS prefixes, since those are rarely needed these days anyway.
It's way too granular to be handled through the legal system or any kind of government regulation, so it's an unfortunate situation that's going to keep happening.
Now they can bypass any W3C standards-comittee and launch whatever they want in production websites and their own browser at the same time, much like Microsoft did. They already have their own Googley version of ActiveX out there! It will be fun to see what's next! /s
Google Chrome is the worst thing which has happened to the modern web.
I'd be inclined to agree, but then Google did start spam-binning its own security notifications a while ago and didn't seem to notice until Linus Torvalds started blogging about the rise in spam false positives. "Never attribute to malice what can adequately be explained by incompetence" - that is the Google motto, after all. ;)
Amen.
I agree with the commenter below who suggests we use random strings instead. Unless there is some sort of published standard for what this header should contain and what each byte means, the contents may as well be random.
The "history" of "user-agents" (about 20 years) is not very long, assuming the web is going to last more than 20 years into the future. Taking a long view, we are still in the nascent phase.
Not so much for deciding what to serve to a request, but moreso to analyze your audience and figure out from a technical perspective what is feasible and what is not. For example, a recent decision I made was to decide whether or not to rewrite a portion of our application in a javascript framework that did not offer IE8 support. I was able to quickly validate what portion of my userbase I was affecting by looking at user agent strings.
Request headers are a fantastic way to capture this little bit of information. Using javascript feature checking depends on a javascript engine successfully loading and parsing whatever scripts I've provided to the client. Request headers are simple plaintext that don't fail in even the most bare bones of situations.
No need to do browser detection. Just make your site work without JS as well :)
Nothing ever guaranteed the user agent header would be consistent or present. Any re-use of a user-agent string adds bits of data that can be used for tracking.
Have a css media query for every possible height, and every possible width, that loads a 1px empty png.
I double it's a bug, it's not the first time it happened, when YT introduced full HTML5 mode, there was a bug that for firefox, and only for firefox youtube was serving video with incompatible codec, the same as for Chrome, but Ff didn't have that codec implemented yet, so video didn't work. Opera was served video same as before, I noticed on reddit and other forums people were complaining on Firefox, that it stopped working on youtube. People started posting "I'm moving to chrome because it works". I think it's a plan to annoy firefox users by serving them not compatible videos so people move to Chrome. Google IS internet.
It doesn't seems impossible to me they missed this specific case.
I really don't get why we can't just have a "fuck it" mentality for user-agent string. User agent has been the biggest technical shit debt I have ever seen so far on the web.
1. Fuck the existing user-agent string.
2. Simplify to Browser-name: version
Anyone depending on existing scheme will find failure and they will update after googling a bit. Sure there are many variations / forks, and those should identify themselves either with the upstream or decide to advertise herself. The only problem is people running old version of browser as those won't get any updates.
Sorry for the language, but seriously, fuck the existing user-agent detection. The only reason I find user-agent still useful is simply tracking the % of chrome/firefox/edge/ie/safari/mobile users, and that's all web analytic people care about as far as browser choice is concerned.
User-agent is unreliable and should not be trusted.
You try to implement that in your browser and launch it, and many websites will break (banks, in particular).
Users will download your browser and find that it doesn't work on [FAVORITE SITE X], and they won't blame the site, they'll blame your browser. After all, [FAVORITE SITE X] worked with the browser they used previously to yours; clearly, it's your fault that the site doesn't work now.
So we continue to make incremental changes and work around issues with popular sites needing to sniff user agents, while authors of new sites (that someday become popular) continue to work around issues with popular browsers by (ideally) checking the DOM in JavaScript, and (sometimes of necessity because the data of interest isn't available through the DOM for security or design-hole reasons) sniffing the user agent.
Why? We have JavaScript feature detection for video tags: http://diveinto.html5doctor.com/detect.html#video-formats
I've worked with video format streaming, though, and encountered a situation where there was a driver on a certain Android device manufactured by a major hardware vendor that you've certainly heard of, and their driver silently corrupted video that was using low-latency streaming options. And by "corrupted" I mean that, while a few of the pixels looked almost right, sometimes, it was mostly just garbage and blank grey screens.
I gave them a sample stream that failed, and they verified that yes, it's their fault. And that no, they weren't going to ship an update for it. Sorry. Device had been out for two years. Apparently no one thought to actually test the various standard options in that video codec. It works with the "normal" options? Ship it!
So I totally understand the need to look at UA strings. I had to look for that particular device hardware profile and disable the low-latency streaming options in order for our product to work on that device.
Edit: Not saying that's always correct, but there does seem to be a tension between: "make sure your code can work well, even in a bad environment" and "don't mask bugs, instead fix them where it makes the most sense to do so" (in this case: in the dozens of browsers instead of in millions of websites).
If a mechanism exists to prevent your customer from perceiving this, as a business the smart decision is going to be to use it.
"i'm getting a lot of corrupt unsupported browser when accessing video on other sites, so i'm using chrome. i can't figure out if it's flash or firefox but i'm tired of opening the hood, i'm done with FF for now"
Most of them looked for a workaround and spoofed the user agent, but they are the kind of people that fiddle with settings. Normal users probably either don't notice or change browser.
Finding workarounds for browser bugs is a common theme for the work that web developers do. Yes, browser vendors should fix the bugs, but in the meantime, there's no reason to have a bad user experience.
> Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
Google Chrome tells us it is: a Mozilla, it is AppleWebkit, it is KHTML, it is Gecko, it is Safari, and it is Chrome.
"Meaningful" is something different.
You might object to the form of the communication, but that doesn't render the communication inexact. Just think of it as browser slang.
This is true, which is not particularly useful when deciding if a feature is available. Using the user agent to make this decision incorrectly assumes that all user agents of a particular browser+version all support exactly the same set of features. This is obviously not true.
The user agent may be meaningful[1], but the meaning that it communicates isn't feature data.
[1] If you take the header at it's word; as the bug being discussed demonstrates, user ages may be lying.
But it kind of is (to some degree, at least). VP9 was recently added to Firefox 28. If the User Agent says the browser is Firefox 27, then you probably shouldn't try serving VP9 to that browser.
Obviously the User Agent doesn't communicate the complete feature set. But some useful inferences regarding features can be derived from it.
It's not like YouTube is a company of full of nothing but dopy idiots. I don't think they'd be using the User Agent if there was a better alternative.
If I don't have this line in my .wgetrc, I get 403's sometimes from sites using Cloudflare.
user_agent=Mozilla/5.0 (compatible; CloudFlare-AlwaysOnline/1.0; +https://www.cloudflare.com/always-online)
Find the corresponding info from the company or their CEO, use that.
And whenever some site wants me to register for a newsletter, I enter their own "critical support" mail address.
I hope at some point these sites learn that mandatory anything just hives you useless data.
Added benefit of getting alot of "not recognized computers" or whatever emails from google lol
As far as I am aware, no extension currently offers the option of a random user agent, but many (including the one linked) allows user supplied use agents, and there is no reason you could not make one support random user agents.
Note that plenty of smart companies have things like production freezes at holiday times :)
So this is not entirely surprising.
(they are always exceptions in any of the companies i've been in, but that's been the rule)
Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136
Tons of videos from then are only available in those resolutions, and I don't think it's productive to close the tab any time you encounter a video from 2007 or 2008.
The average screen resolution in 2007 was 1024x768. Most of us now have ~1080p-ish type screens or on mobile where it's even higher. We also now have the bandwidth to watch 720p/1080p videos whereas in 2007 that was less true to a broader audience.
360p is pretty unwatchable for me on my screen from 2011/2012, let alone anything that's been released in the past 2 years.
I also know a lot of people who just start a playlist with music and leave YT in the background the whole day. They don't even have that tab active in the browser.
http://www.h3xed.com/web-and-internet/youtube-audio-quality-...
Luxury problem - I frequently get no video at all because of geoblocking when I use Tor. Youtube is really a terrible video site and I don't see why everyone is using it.
As for the case with google products, particularly youtube, those users other than ones using chrome have a really mediocre experience. Try viewing a youtube video on chrome. you won't experience a problem if you quickly try to seek backwards. Now try doing the same in firefox. This is one of the reasons I stick with firefox, which supports open standards and privacy.
So, a bug in YouTube's compatibility-autodetection caused it to fall back to a slower, bitrate-limited fallback method that it didn't need to, for some versions of Firefox. They took two weeks to deploy the fix. Considering those two weeks included Christmas and the bug didn't affect security or render the site unavailable, this seems like a pretty good response time.