There are now at least eight Chromium-based Android default browsers | Hacker News Reader

There are now at least eight Chromium-based Android default browsers

quirksmode.org

238 pointsmmastrac122 comments

Curmudgeon time: reflow and zoom were probably my favorite features of the original Motorola Droid browser. There were zoom ( +, - ) buttons in the lower-right to zoom in and out -- accessible one handed, with your thumb, none of that pinch-to-zoom nonsense. And the text reflowed on zoom!

Further iterations of Android slowly stripped out these features -- first the buttons went, in favor of pinch-to-zoom, then reflow in favor of... a worse user experience.

Most sites with a lot of horizontal text (hello, HN!) are hard to read in portrait mode without constantly scrolling. Phones are faster than ever, I don't see why computational requirements would be a good reason for disabling reflow. Turn off all those damn animated-transparent-rounded transitions and give me back my reflow.

As far as I can tell, none of the major mobile OSes (Android, iOS, Windows Phone) ship with text reflow in the browser by default. Well, except HTC Android, according to the article. And that is maddening.

On Android, in most places where you can zoom (browsers, Maps, etc.) you can zoom one-handed with a double-tap (where the second tap is held down and dragged up or down to zoom in or out before releasing). It's actually a pretty smooth interaction once you know to do it.

I've used android for years and never knew you could do this. This is one of the things I hate most about all those gestures : there's no way to know about them unless you just try a bunch of random things, or you google for "android browser gestures" or something like that. Give me buttons to do the same things those gestures do! Hide them behing menu if you want, but give me functionality that I can use right now without having to hunt for them on the web.

From google maps on my one plus. Menu > "Tips and Tricks" > "Zoom in and out in more ways than one." I didn't know about it either, but it took a minute to find the how to explanations. Personally I prefer standardized gestures to buttons to save the screen space, but thats just me.

Another gesture you'd never know you could do - double tap with two fingers will zoom out in google maps (e.g., the inverse of double tap with one finger). I think this works on both Android and iOS.

FWIW this also works in Google Maps for iOS. I wish it worked system wide.

This is kind of system wide on iOS. Almost all apps that support zoom supports double tapping to zoom in. Safari zooms into the HTML element you double tapped on and fits it nicely on the screen.

If it helps, double-tap (or sometimes long-press) to zoom occurs in many photo apps on various platforms.

Yes, this gesture is actually amazingly better than pinch-to-zoom, my only annoyance with it at present is that Android Firefox doesn't implement it - the only app on the entire platform that doesnt have it.

No idea why they think it's OK to ignore system wide standard gestures for years, but it's an obviously improvement that can't take much work to put in place.

The removed text reflow function in Android brought me to tears and Google does not intend to fix it.[1]

Opera for Android is the only option that does this really good right now (in a browser that doesn't feel like a malware data collector).

Lightning browser (open source) released an update this week that brought text reflow to post Kit Kat devices, but the way the text reflow works doesn't come close to the original Android implementation or Opera. Just try it on Hacker News.

[1] https://code.google.com/p/android/issues/detail?id=62378

I use Opera Mobile on Android since it is available. The only reason for me is that the zooming and reflow works like I want it to.

same here the text reflow is a must, it also has my favorite tab management of the mobile browsers

Try Lightning. Its a bit buggy and unfortunately put tabs at the top (whyyyy ..) but zooming and reflow are like opera mobile assuming you mean the classic one, not the one with random font sizes.

My experience is that Lightning text reflow doesn't work at all like pre Kit Kat Web View text reflow. How have you configured Lightning?

Hm, what exactly are you looking for? I am on 2.3 so maybe it's just using some OS provided stuff, if so, sorry for the useless suggestion. For me it seems similar to what I remember from the stock browser and the good old opera mobile before the drama (rip...).

Reflow works on mine (4.2.2 android, default browser). You need to pinch to zoom, but then a double tap reflows. [It took a while to stumble across it, and then another while to realize what that sudden weird thing actually was.]

NB: I have Settings->Avanced->"Auto-fit pages' checked (4th from bottom). Maybe that helps.

It works pretty well, but as others have said, apart from indented (or monospaced "code") text.

BTW: double tap and move up/down to zoom doesn't work in that broswer (though it does on the Google Maps app).

Yes, Google removed that feature in Android 4.4, breaking the user experience and not going to fix it again:

https://code.google.com/p/android/issues/detail?id=62378#c11...

This HN comment thread is unintentionally funny because of all the people talking about a thing that got removed in a version after the one they have, and saying "well I don't know what you're talking about!" Yeah, you don't. Sheesh.

Reflow on pages with indented text, as HN, is a borderline mess. More often then not the text is reflowed but the indent preserved, thus requiring horizontal scrolling to bring the full text into view...

Which is the proper way to do it... The alternative being ending up with a 1-character wide column of text.

Except that people want reflow exactly to avoid having to do horizontal scrolling.

Then again, most of the time what is wanted is not so much zoom as the ability to bump up the font size.

I want reflow to avoid mid-line horizontal scrolling. I don't really care if each block of text gets offset.

Yeah, exactly. I want one chunk of text to be legible in one frame. I don't care if I have to scroll chunk-to-chunk.

This doesn't solve the reflow problem, but you can double tap to zoom, too.

I always forget Android supports pinch. I never use it, myself (don't like needing my other hand except when typing).

iOS Safari sometimes increases text size automagically.

http://stackoverflow.com/questions/6210788/how-to-avoid-ios-...

I worked on the front-end of a mobile/tablet online shopping tool for a big 5 automaker for about a year and a half.

At the end of all of it, if anyone asks me what I recommend for mobile/tablet web development (and they usually don't because everyone presumes the standard is pixel-perfect app-like appearance/behavior), it's simple layouts that accommodate the idea that your CSS is a suggestion and lightly enhanced interaction with not-constantly-running JS... unless the product absolutely requires some other mode of interaction.

There are a number of reasons for this, but one of them was exactly this problem with Android. During the time I was working with it I don't think we ever thoroughly cracked what signifiers would help us reliably reproduce reported issues... let alone fix them (you can detect a whiff of my desperation this time last year from this unanswered SO question: http://stackoverflow.com/questions/23142762/how-to-identify-... ).

Not my problem anymore. Last I heard the new owners are planning to rewrite with more responsive design and using angular. Should be fun.

It isn't just Android anymore. A project I worked on has been getting a lot of reports of layout issues on iOS for alternate browsers like Chrome. We have no issues with Safari but the alternates seem to throw some wrenches in the system.

Chrome on iOS does all rendering using the native iOS WebView. Rendering should be quite consistent with Safari (although JavaScript may be slower). Chrome differentiates by implementing their own network stack and browser "chrome" (tabs, history, favs, etc).

JS is no longer slower than Safari since 8.0, if you use a WKWebView

http://9to5mac.com/2014/06/03/ios-8-webkit-changes-finally-a...

Which Chrome doesn't do.

https://www.quora.com/Why-doesnt-the-new-Chrome-for-iOS-use-...

At least these aren't the default on any phone though, so their usage statistics should be relatively low.

The worry with Chrome for me is not that these issues happen, but that they seem to be slow in fixing them. I'd hate to find Google have pulled resource now they have a dominant position in the browser market and will languish in the way older version of IE did.

Another important thing is Chrome's rapid release process works under the assumption that most issues that crop up will be fixed quickly in a later version, rather than be back-ported. Which is to say that there are no Ubuntu-esque LTS versions of Chrome, so whatever random bugs happen to exist in the version of Chrome that each vendor forks will likely be there for a long long time, making this fiasco that much worse.

Seems like Google is trying to apply web development methodology to software...

What does this have to do with web development in particular? Regardless of the kind of software involved, if YOU fork, it's YOUR responsibility to merge upstream patches and fixes over time. If the various vendor-branded Chromia aren't doing it, then it's entirely on them. Upstream Chromium is open source, and the code for all of those fixes and patches is available in the open.

Don't bother with a LTE/patch-only branch, just "iterate iterate iterate" as the just user coming down the net connection will get your latest anyways...

Maintaining a fork as complex as Chromium is probably more work than these companies are willing/able to do.

Then they shouldn't fork it.

I don't know but they removed the reflow from the browser used in Motorola E 2gen and for me who only uses it for reading on the tube this almost made it unusable.

I can only read in horizontal mode or scrolling left and right on every row.

I set opera as the default browser because that supports it but apps like Pocket are unusable for reading stuff like HN comments.

According to them it's a wontfix.

http://code.google.com/p/android/issues/detail?id=62378

This makes me so angry, I wish I wouldn't have upgraded from a Huawei G510... I feel I wasted my money on shit.

If you're looking for another browser with reflow support, Firefox on Android supports it.

It also has a reading view feature.

For those who don't know, it's the little book icon in the URL bar. Took me forever to realize that it wasn't a bookmarks button.

Just yesterday I noticed the same feature has started showing up in Firefox Developer Edition, which means that I can replace Evernote Clearly (seems to work better than Clearly, too).

How does one use it? Apart from reading view?

If I understand correctly, you are asking the browser to provide a workaround for a website that isn't optimised for mobile, and asking that browser to maintain that workaround forever?

I'm surprised they ever tried to do this in the first place.

Reddit has now had a hell of a long time to deliver a mobile-optimised site, responsive or otherwise. I feel like your criticisms would be better directed towards them.

Edit: Btw I'm sure some people may comment that it's not just Reddit and there are 1000's of sites that were more easily viewable on a text-wrapping Android browser previously. That's undoubtedly true, but how will the web ever move on from its fixed-width-desktop-sized past if we don't force the offending websites to fix their broken fixed-width styles. We can't workaround that bad idea forever.

It isn't even a workaround. This has worked by default in all browsers since the days of Netscape Navigator and probably before. You don't need media queries or even css.

1. Put a bunch of text in your body tag. 2. Open in a browser. 3. Resize your browser window. 4. Note the reflowing text.

This has been standard behavior for decades. I've never seen a desktop browser that doesn't work this way. Why should mobile browsers be different? (significantly worse, specifically)

Exactly. IMO all css/html features that conflict with this should be deprecated and REMOVED from the standard.

Right, let me just go ahead and file an issue with the WHATWG to deprecate `width`

>If I understand correctly, you are asking the browser to provide a workaround for a website that isn't optimised for mobile, and asking that browser to maintain that workaround forever?

Yeah, why not? Programs exists to help their users. I could not care less if the website developers are sloppy or whatever, if the browser can give me legible text, it should do it.

Because, like the other downvoted-for-no-reason commenter posted that's great for you in the short-term but bad for all of us in the long-term. Far better if people fix their broken sites. It's analogous to why we as a web developer community suffered overall by 'supporting' IE6 with crazy fallbacks instead of just saying no.

The web, as originally envisioned, was supposed to be user agent agnostic. The user agent (AKA browser, search engine, personal AI, braille terminal, screen reader, etc.) would interpret the page and process or display it appropriately for the agent's purpose and medium. Thus, sites shouldn't have to adapt to mobile; it should be possible to write one semantic site that looks right on any device, because the user agent is supposed to do the formatting.

Removing that ability from user agents is counter to users needs and the basic design of the web.

>It's analogous to why we as a web developer community suffered overall by 'supporting' IE6 with crazy fallbacks instead of just saying no.

The reason the "web developer community suffered overall by 'supporting' IE6" is because people wont and dont update their "broken sites". That's a pipe dream. Some are abandoned, others are maintained by amateurs who don't know what they're doing, others don't care, etc.

Users still want to be able to read them, and will switch to a browser that does, if yours doesn't. Unless you control all competitors and can co-ordinate a mass update, you better support them.

>> The reason the "web developer community suffered overall by 'supporting' IE6" is because people wont and dont update their "broken sites". That's a pipe dream.

I meant that we wasted a lot of effort building IE6-proof sites in recent years. My analogy itself had nothing to do with updating sites. I was trying to give an example of a 'crazy web workaround' that screwed us over in the long-term.

But if we forget analogies and I address your actual claim that:

> [...] people wont and dont update their "broken sites".

We're talking about major sites here (like Reddit) where this is clearly not true as most have updated already. Reddit is something of an exception, though they are clearly working on it as the commenter that linked to the beta `m.reddit.com` has shown.

From your perspective that is true, of course, but it is a greedy perspective that optimizes locally at a cost to the entire ecosystem.

Personally, I find something enjoyable about viewing desktop websites on mobile and zooming in and out - something about an instinctive sense of place (navigation in two dimensions rather than the usual one of scrolling), combined with being able to navigate a truly densely packed interface on a small screen, rather than having to pare things down to some extent as you see in most mobile websites and apps, feels vaguely empowering. At its best, this creates something of an accidental zooming user interface[1]. A particularly good example is the New York Times desktop homepage, where zooming around something vaguely resembling a physical newspaper, organized by topic in a predictable layout, is just nicer than scrolling the linear list of articles on the mobile homepage, with only a few visible per screenful - it's no accident the former was featured repeatedly in earlier iPhone keynotes and advertising. These days they send mobile browsers the mobile site by default, but thankfully it has a "view desktop site" link; "modern" responsive websites may adapt better to screens of varying sizes, but they have the annoying side effect that you typically can't get to the desktop layout on mobile. (This would be pretty easy to fix for either the site or the browser, but I've never seen it implemented.)

I don't know where you got Reddit from, but it has not only a modern mobile website[2], but multiple client apps available on iOS and Android. Yet I read Reddit on my phone exclusively using the desktop site. Same goes for Hacker News and the various third-party webapps and native apps.

I've never used a non-iOS mobile OS for an extended period of time, so I don't really know what automatic reflow feels like in practice, but I can certainly imagine it would be useful to people with similar preferences to mine, in a way that mobile sites don't substitute for.

[1] http://en.wikipedia.org/wiki/Zooming_user_interface

[2] https://m.reddit.com

> I don't know where you got Reddit from

Reddit is the example given in the thread parent (luos) linked to.

> but it has not only a modern mobile website[2]

Here're the exact first words from the m.reddit.com link you posted:

"Welcome to reddit's new mobile site. This is in beta"

reddit.com does NOT redirect to this site when you visit it on mobile. The thread parent linked to is entirely about Android Chrome accommodating non-mobile optimised sites like the current reddit.com, which is the canonical example given.

http://www.reddit.com/.compact is still better

This doesn't mean "welcome to reddit's site, which is new on mobile", it means "welcome to reddit's mobile site, which we have just revamped". They've had a mobile site for years.

> Android 4.3+ devices, including those by Samsung, HTC, LG, Sony, Huawei, and Xiaomi, have their own default browser on the homescreen

What exactly is he talking about? I have a Sony Xperia Z1 Compact and on the home screen i have Google Chrome and Google Play Store claims i have the official Google Chrome version installed and the only other browser i have on there is firefox.

What's your Android version ? They might have changed it and set Chrome as default in Lollipop.

I am indeed on Lollipop, however even before that, on, i believe 4.4.4, the situation was the same.

Google began pressuring more Google apps since Kitkat yes, but Z1 started with JB and I presume that where the stock AOSP browser still was.

> Oh, and remember that Chrome on iOS is not Chrome at all, but Apple WebView, which on iOS8 is supposed to be the same as Safari. That’s because you are not allowed to install other rendering engines on iOS.

What exactly does this mean: Does Apple review and reject apps that have a rendering engine, or does iOS have some magic to prevent other rendering engines from working?

I had no idea that Apple had this restriction on apps. Quick search pulls up article to show that this is indeed the case [1]. This seems incredibly restrictive especially particularly since Microsoft got into substantial trouble just for bundling internet explorer back in the day [2]. Are there any technical reasons for this restriction?

[1] http://www.howtogeek.com/184283/why-third-party-browsers-wil... [2] http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.

> Microsoft got into substantial trouble just for bundling internet explorer back in the day

No, they didn't.

They got in trouble for attempting to protect monopoly power in the desktop personal computer operating system market and extent that power into other markets by, among other means, bundling IE.

That restriction is why there is no iOS Firefox.

Developers can not bundle their own runtime and execute code that they download from the Internet. My understanding is that this constraint results in increased security and performance, while also ensuring that Apple keep their control on what runs on the device.

iOS has its roots in web apps. The original iPhone didn't support third party apps, and Apple was pushing developers to use web technology to make apps. This attitude persisted for a long time and to an extent persists even today.

When they introduced apps, they didn't want web apps to run differently in, say, the embedded browser of an RSS reader, than in Safari, because users have no clue that there's such a thing as different rendering engines and would be confused.

Of course, for a long time, WebViews and Safari used different versions of webkit, but at least they had identically implemented APIs for integrating with mobile hardware and such.

I was curious so I went and looked it up in the App Store Review Guidelines

2.17 Apps that browse the web must use the iOS WebKit framework and WebKit Javascript

>Does Apple review and reject apps that have a rendering engine

This is the answer

Iirc, it is not strictly the render engine that is the issue but the JS engine. But quite often those are most often lumped under "render engine" by tech sites.

The former.

In which we compare an open source project that people are compiling and building versions of (Chromium), with a Google Product (Chrome), and pretend that versions of the former are versions of the latter.

In other news, GCC continues to fall apart at a brisk pace, with literally every distro shipping slightly different versions.

Any misrepresentation of Chrome (product) vs Chromium (project) is uninteresting and unrelated to the main issue highlighted in TFA.

The main issue is: "(mobile) Chrome, and the promise of a stable official browser in Android is fucked because everybody ships 4 and 10 versions behind custom versions of Chromium, so its Android share and the hope of a single modern browser for Android users is slipping".

>In other news, GCC continues to fall apart at a brisk pace, with literally every distro shipping slightly different versions.

That's indeed one of the problems with GCC, btw.

"The main issue is: "(mobile) Chrome, and the promise of a stable official browser in Android is fucked because everybody ships 4 and 10 versions behind custom versions of Chromium, so its Android share and the hope of a single modern browser for Android users is slipping". "

The conclusion does not follow, because nobody has ever, AFAIK, promised the stable browser was "internet" or "browser" or whatever the hell they call it on each phone.

Chrome should exist on all of these, if you want a stable , modern, browser, that's it.

Android webkit should also be the same on all of them (AFAIK).

Past that, forcing "internet browser" on various phones to be the same would be exactly the behavior that MS had trouble with.

>Past that, forcing "internet browser" on various phones to be the same would be exactly the behavior that MS had trouble with.

No, the behavior Microsoft had trouble with was abusing its monopoly position in the PC market. Google is not a monopoly in that sense for mobile OSes (the vendor of something is not considered a monopoly in its own product, e.g. Apple is not a "monopoly" on iOS, it's just its vendor. The "monopoly position" applies or not only in relation to the general market, not within a single product).

> In other news, GCC continues to fall apart at a brisk pace, with literally every distro shipping slightly different versions.

Heh, this is actually true. Clang/llvm are rapidly replacing GCC, largely due to this issue (though performance plays a part as well).

There's also some complication from GCC being developed as part of GNU. You'd think this wouldn't be a problem in practice, but I remember (yet can't seem to find, unfortunately) a rather significant spat on the GCC mailing lists about the more hardcore GNUsiances refusing to implement a better AST (or at least one as good as clang's/LLVM's) solely because doing so would run the risk of the AST being used to reverse-engineer GCC beyond the terms of the GPL and a bunch of core GCC devs threatening to fork and ditch GNU because of it.

Do Linux distros that have their own patches for GCC not have their own patches for clang/LLVM? Why would this be the case?

They haven't had time to accumulate patches that were useful five years ago but now just make things pointlessly slightly different. Similarly, you can generally assume that if someone has clang then it will be a relatively recent version of clang, because of how fast clang moved from not being practically usable to being very good.

In a few years I assume that all of the various annoyances around targeting GCC on Linux will also apply to clang.

It's not the case, they have patches for both :)

Only if by 'distro' you mean 'Apple'.

Why does this make a claim about Chrome when it's talking about Chromium forks?

First thing to do when getting a new Android phone (or flashing a new rom): Install Firefox

This is up to some combination of the OEM and the carrier.

For instance I just bought a Verizon Samsung Galaxy S6 and it definitely came with Chrome as the default browser and no other browser. However the TMobile version comes with both Chrome and Samsung's S Browser, setting Samsung's as the default.

I can't imagine why an OEM would take the effort to develop a browser when Chrome is there...

If you can't imagine why, for example, Samsung would want its own browser, your imagination is severely lacking.

Oh, this is for the mobile version. I was thinking desktop. I'm getting awfully tired of reading "[Harmless niche feature X] is being removed from Chrome to reduce menu clutter. If anyone still wants it, it should be possible to recreate it with an extension."

What have they removed in this way? IMHO Reducing menu clutter should be done by making an "advanced" settings tab, not by requiring extensions...

Off the top of my head, View Selection Source in the right-click menu, and the ability to set a default background color (so that you can navigate dark-colored sites without them flashing blinding white each time a new page starts to display, and so you can make out dark images when viewing them in a separate tab). Neither one has ever gotten a really satisfactory extension, although there is an awkward View Selection Source plugin that mostly works. IIRC, the default background color was only accessible by jumping through hoops to begin with; they just decided to remove it anyway because...nobody used it? Except for the hundreds and hundreds of people who complained, but they don't count? I read the justification in the bug report and I still don't get it.

I've seen at least three others that I can't recall right now. It's really, really annoying.

(There's also the thing where they are in the process of deprecating NPAPI, which among other things means permanently killing support for browser games written in Unity. That at least has some technical/security justification, from what I've heard.)

> View Selection Source in the right-click menu

AFAIK, Chrome has never had "View Selection Source" in the right-click menu. Firefox does, maybe that's what you're thinking of?

Maybe. There was something to do with source in the right-click menu that was removed for no good reason, but it was years ago and I can't recall the specifics.

(Someone has downvoted my parent post. Baffling. Defensive Chrome dev, maybe?)

When Apple first said they would only allow a single web rendering engine on iOS, at first I was heavily against the idea. But now as a web developer who is absolutely not looking forward to the inevitable "people running around with 10 version out of date Chromium browsers", I'm starting to think Apple had the right idea. I can test a website on a single iOS device and know it will work the same on all devices in that version of iOS even if they are using "Chrome on iOS" or "Opera on iOS" or any other browser. I have no idea how I'm supposed to test a site for 13 different Chromium forks. And as time goes on, they will only grow more and more divergent from the main Chromium branch, which means they won't have bug fixes or new features.

In theory you are correct, but we ran into an issue that only occurred on the iPhone 6+. Basically we were doing a lot of heavy JS and CSS transforms, and it caused the 6+ browser to crash, and if you tried again the actual phone would reboot. We could not recreate this any other version of the iPhone that we tested.

No one is saying this doesn't happen on Apple devices, merely that issues like the one you describe happen tenfold (or more) on Android and seem to be escalating.

You should develop towards standards rather than a particular platform.

Standards are nice and dandy, real-world-implementations all suffer from bugs, missing features or implement undefined behavior slightly different. So if you want to support an implementation, you need to test it. If there multiple versions of an implementation you want to support, you need to test them all. Any other approach is "it works on X, it might work on Y, but we're not actively supporting Y."

From a practical standpoint, don't you still need to test it against popular platforms though? (If you develop to the standard and a popular browser doesn't support the standards correctly as far as your users are concerned, it is your problem.)

That's a fine thought, until Chrome adopts a new standard in Chrome v46, but half the Android population is still running Chrome v38.

I have no problem with the forks. I have a problem with the fact that they will absolutely not be kept up to date. The article already mentions that new LG phones are being sold with a Chrome fork 4 versions behind the one on the newer LG phones. In time that gap is only going to widen.

And that's just the shiny new features. There are constantly bugs (including security issues) being fixed. What about those?

If every browser vendor fully and correctly implemented a standard on their first try, you'd have an excellent point.

As it is right now, even people that develop towards standards still have to choose between deviating from those standards to support a wider audience or sticking to the standards and turning away users.

In the most general sense, deviating from standards does not support a wider audience.

Do any platforms implement the standards completely and consistently however?

No, it's inherently impossible as it's a moving target. However it's important to strive toward that goal. It's part of the whole point of what makes the web successful. Once you give up and start developing for some particular platform you risk corrupting the space.

Hahaha, good one!

It depends on what your business is. The other reply says to develop toward standards, but that is in the hope that browsers will adhere to those standards. What we do is run serious analytics against our page views and see what customers are using. We see that iOS is the highest, and Samsung flavored android are the next highest. So, we cater to those devices. We do test for regressions on a few other devices, but not as heavily, since those are not what our customers are using.

If you're developing an app for Android that uses WebViews, your best bet is probably to start using Intel's CrossWalk project. At the cost of quite a few dozen megabytes in app size, you get the latest Chrome (well, the latest when you published your app) plus a few of Intel's pet web projects (SIMD, TypedObjects).

That said, as annoying as it is that Safari on iOS is slow to pick up new web technologies, atleast I know that the vast majority of iOS users are using a browser updated within the past year, and it's all the same browser engine underneath.

Welcome to my personal hell. Samsung used to be the worst but HTC may have usurped that position.

- Cordova-based Android app developer

I left my last job after management sold a Cordova solution. We didn't have the tech in-house to dev/test, but had already sold it anyway, leading to a death spiral of developer hell as we needed to support Android 4.0.1, our Android test phone was a $30 LG which barely displayed the home screen. iOS worked great — or at least, predictably enough to repro + fix anything we caught.

> our Android test phone was a $30 LG which barely displayed the home screen

Ugh I know this pain, I did some Titanium Appcelerator development for a while and I had the newest iPhone a previous gen to test with but the Android phone was worse than bargain bin. It really skewed my perception of Android and it was hell working with such a shitty device. On top of management wating it to work on super old phones (needs to work "everywhere" and my QA consisted of me with a single phone and a laptop that could barely run the simulator (which was really shitty back then, I've heard it's gotten better). I hated that shit.

You can use CrossWalk to ensure you have the same Chrome version across all Android devices. That said, it does make the APK very heavy.

> Although Google Chrome is installed on all Android 4.3+ devices

Is this correct? My phone (Galaxy S3) is running Android 4.4.2 and Play Store tells me I don't have Chrome installed.

I would like to know what behavior is different with some real examples of broken functionality.

Jesus, what a disaster.

so nice to see a quirksmode post in front-page again!!

ahh the nostalgia

I wish it was working at least on Yosemite properly.

But Android is _open_ !

I don't think Google is putting much resources in Chrome. I ran into a bug where I had to multiply all coordinates in an SVG file by 100 in order for Chrome to correctly detect the "hot spot" in an icon.

It used to be IE that needed the kludges.

I like the idea of having Chrome out there but I am not going to use it.

I like having another serious competitor in the browser market to keep everyone else on their toes.

I find Chrome to be unusable. I can't get past the lack of a menu bar. Maybe that's picayunish but I find it so distracting that I can't use the browser at all.

The usual Google product lifecycle:

* Create new product to great fanfare

* New product sees wide adoption

* Many competitors to new product die off due to Google's monopolistic practices

* Google decide supporting the now-standard product is not lucrative enough and abandon it

* Massive ecosystem gap

I see Chrome on the desktop moving in this direction. It is massive and bloated and has become the thing it was designed to overthrow. One process per tab does not scale. Chromebooks are becoming less and less relevant. Surely the mobile situation is indicative of reduced corporate support for the project as a whole.

> * Create new product to great fanfare

> * New product sees wide adoption

> * Many competitors to new product die off due to Google's monopolistic practices

> * Google decide supporting the now-standard product is not lucrative enough and abandon it

> * Massive ecosystem gap

In my lifetime this has gone from describing Microsoft to describing Google. Amazing!

Meanwhile, Microsoft has gone on to open source core components of their offerings (with no signs of slowing down) and Apple (not surprisingly) is locking down developers even further with requiring signed drivers by default (I think -- not confirmed). Amazing how things can shift.

To be fair, it's not hard to get a signing key for Apple (anyone with $99/yr can get one). And it's not just drivers -- ALL apps must be signed by default.

Google open source stuff, true, but their development practices leave much to be desired, and in some cases seem designed to limit the usefulness of the source.

Chromium source is a nightmare to build, and requires random, specific versions of the opensource components, or sometimes incorporates requires Google's own forked, slightly different and broken versions.

Android source is becoming less useful as a viable OS replacement every version, as so many apps are tied solely to the Play APIs.

Microsoft has moved to requiring signed drivers ever since the x64 versions of Windows have come out. All 64bit installs only run signed drivers.

Yes, it's turnoffable, but only as a temporary measure and with huge warnings - kinda similar to what Apple does now too (boot parameter, but no warnings AFAIK)

Reply on news.ycombinator.com