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.

https://github.com/tc39/ecma262

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.