This might be due to the result of study showing that the insane bounties Google promises for top end bugs (especially for Chrome) draw many people in to look for Chrome security bugs, but that actually the expected payout for looking for Chrome bugs is exactly the same as it for for (for example) Firefox, because the latter pays more for the easier to find bugs.

Microsoft already changed their bug bounty program significantly days after the study was announced.

You had be running the specific, modified Firefox version that's shipped with Tor.

Mozilla's Firefox 17 (ESR) has been patched for this vulnerability. (i.e. it's not a real 0-day)

Tor ships their own, modified version of Firefox. I guess that's why it's ancient. The exploit they used doesn't exist in Mozilla's version as that has been patched for it a while ago.

Who do you think the W3C is? It's the browser vendors. Who do you think benefits from smaller browsers not being interoperable with bigger ones? Not the smaller vendors, I tell you.

Now, do you think the vendors with the near-monopoly marketshare on Mobile care about making competition in their market easier?

The conclusion was that multi-process Firefox isn't magically going to make the browser more responsive, and will make it use more memory instead. Actually fixing the bugs that make it less responsive does seem like a much more useful spending of developer time.

What do you need a 64-bit email client for? Bigger pointers so it uses more memory?

Depends on what the applications see. In case of Firefox OS, they'll see the Firefox JS runtime. In GNU/Linux, they see GNU libc.

It also works the other way around. Mozilla needs to convince people to use their browser and install it on desktop. If you get a Firefox phone (because it comes with the plan or whatever), you don't need to be convinced.

It's the same engine as desktop Firefox. What you're seeing is that a lot of websites send "Webkit-only" markup to Android devices. (Dolphin uses Android's rendering engine) This is something Firefox can never fix. There's an add-on that makes it pretend it's desktop Firefox, that generally stops misbehaving sites from sending broken markup. I suspect most sites will get their act together eventually.

I don't see the "slanted font" problem you talk about on my Galaxy S2, so that's rather strange. The "small font" problem can be solved by setting text size to "tiny" (yes, it's pretty retarded that you have to do the exact opposite of what you would expect, from what I understand it's because that option is completely misnamed).

News to me, to be honest. But in any case: we're quite some years later now. Maybe the Firefox phone won't be too late, but the iPhone was too early instead :P

What? Bandwidth is irrelevant there. If it's bad, both the HTML/JS based app and the native App will suffer. If it's offline, neither of them cares.

Odds are pretty big that the first phones will be ones originally mean for Android.

The main hurdle for late comers would be the apps ecosystem.

From what I understand they're banking on the fact that writing an app for Firefox OS will use the same technologies as making a webpage, which should make it viable for a huge developer community. Apps for Firefox OS will also run on the desktop browser (and the reverse), which isn't something Android or iOS can do.

It's an interest situation, for example if you compare to the need to totally recode everything for Android (Java) and iOS (Objective C).

I'm guessing that is how Firefox development already looks right now, they have 300M users or something thereabouts? Compare the "Bluetooth headset disconnecting" to "Firefox leaks memory, oh and I have these 20 add-ons installed".

Let's hope the restriction to low-end phones keeps this firmly in check. I know loads of people who'd be happy with a cheap smartphone that only has basic functionality (plus web browsing) but not terrible bugs like Android has now...

Security -> The browser already contains a fully sandboxed JS runtime environment since, what, 1995 or something?. They have to do almost nothing there, and it'll probably be actually a lot safer than the comparatively entirely untested Android security model.

Extensibility -> Pretty sure the idea is to just make as much as possible the "original" webpages more usable on a mobile device, instead of requiring the user to install half-assed "apps". There's already API's for pretty much everything in JS.