These are good questions.

even today's high-end devices struggle with a modern web pages.

At some point, designers are going to have to make concessions. cnn.com takes hundreds of MB of RAM to render in Firefox. It's a huge hog, loading hundreds of resources. That's just not going to work on a phone with limited memory; you're right that there's only so much optimization we can do.

But the idea isn't to run desktop Gmail or desktop CNN on your phone. If our competition is "native apps", all of which are purpose-built for the OS, I don't think it's unreasonable to expect app developers to make at least /some/ changes to their sites to make them work well on our devices.

that, and web apps can't tap into the hardware as well as "native" (note the quotes) apps. you can talk about extensions, but then you are asking devs to write FF OS apps, not web apps, and you are right back in WebOS land.

One difference is that Mozilla's "extensions" (and ohboy do we have them) can become part of Firefox and the general web platform. As a simple example, we added an API for reading the state of your battery. That's primarily useful on phones (and I believe we support it on both Firefox for Android and Firefox OS), but we added it to desktop Firefox, too, so you can read your laptop battery's charge.

Of course, not all APIs are relevant to all devices. If you want to frob the device's vibrator, well, that's probably not going to work so well on a laptop. But the idea is for all of our extensions to become standardized (that is, to no longer be "extensions"), and for them to be available on more platforms than Firefox OS, where applicable.

i'm sure you can rattle off some differenes between FF OS and [WebOS and iPhone web apps] but unless there's something profoundly different from the user's perspective, i don't see it.

Well, WebOS didn't fail because the web stack was a fundamentally bad user experience; in contrast, I know a lot of people who really liked the UI. It failed for a variety of reasons, but in terms of UX, it wasn't particularly performant. In this realm, I think Mozilla is in much better shape: We have a large team of Gecko experts working on the performance of our device; thus far, we've been able to get pretty decent perf on super-low-end hardware. In contrast, Palm didn't have any expertise in WebKit, and this has been cited as a reason they were unable to make it fast.

For all the talk about "native" apps, keep in mind that Java is not a native instruction set. It's interpreted and JIT'ed on Android just like JavaScript.

Well, smartphones all got native progams because anything else is just too inefficient. I don't really see what's changed.

The question is whether the inefficiency was a result of web technologies themselves, or their implementations. I don't think we have a definitive answer to that yet.

The developers of WebOS simply didn't have the kind of expertise with WebKit that Mozilla has with Gecko. We're able to optimize the hell out of this thing.

there's this little company called Google that has this thing called ChromeOS. it is EXACTLY [Firefox OS] ... an OS that boots into a browser. it's not lighting the world on fire either.

(Firefox OS developer here) This is a common misconception, but Chrome OS is a lot different from Firefox OS, at least from an architectural perspective.

Chrome OS is, as you say, an OS that boots into a browser. You're running a full desktop Linux client, including a window manager.

In Firefox OS, the window manager is an HTML page. Gecko (that is, Firefox) shows the window manager. All your apps, are iframes (with special attributes on them). The browser is an app (a special iframe). The browser's tabs are more special iframes inside the browser iframe. There are a lot of iframes in Firefox OS.

Also note that Chrome OS is not targeting smartphones (afaik). It's really quite different.

If they'd sell me an iPhone with voice only service and let me access WiFi only for my data, I'd be on-board, even at $600 up front

T-Mobile value plans are $40/mo for 500 minutes of talk plus 2GB of data. That's what I was paying on AT&T just for voice.

You have to bring your own phone, and the iPhone is not compatible with their 3G network. But I like my Nexus S well enough.

I actually thought this was a joke at first glance. So overall they went from white, to grayish, to grayish with some noise, to this. It's so nice working with such a consistent interface.

If only we had more observant people like you using the nightly channel and filing bugs, we might have avoided this rigamarole altogether!

Noooo it is NOT having "security vulnerabilities" because the Pale Moon devs are fixing holes and porting patches themselves so that is not a problem, and they have already said in their forum they are sticking with the V12 UI because they don't like what the Moz roadmap looks like.

Could you link me to this? Here is a post which implies that they have not forked, and are planning to port FF15. I could not find any discussion about porting security fixes on the bulletin board.

Isn't that the point of FOSS? If you don't like the direction you can fork? Well that is what they did, they forked.

Indeed (*), and if that's what they're actually doing, more power to them. I just hope you and others on /. don't get burned assuming that this software is secure.

(*) Although I should point out that this guy is not, in my view, acting in the best FOSS faith, regardless of whether he's complying with the license. In addition, if he is backporting security fixes and not releasing the resultant source, he may be in violation of the MPL.

I've seen with my own eyes the difference on an Athlon X2 I keep at the shop. FF is a little piggy core hog while Pale Moon isn't slamming the shit out of the cores. [...] FF sucks major ass on older chips like Pentium Ds and Athlon X2s while PM is snappy.

If you have a reproducible benchmark or testcase, I'd be really interested to see what's going on. We use SSE extensively on hot paths in Firefox, and our assumption has been that having the compiler insert it elsewhere (as PM does) would not be a win. If that's not correct, I'd like to know.

Try the beta (FF15); it fixes most memory leaks in add-ons.

Actually, this is fixed in Firefox 15. Go download the beta and try it out.

If you are on Windows try Pale Moon [palemoon.org] which has forked away from FF as of V12 because they too grew tired of UI changes.

Firefox is currently at version 14. If you're using Firefox 12, you're using software with known security vulnerabilities.

It's not clear to me that the Pale Moon guys have actually forked Firefox at version 12; it may just be that they haven't upgraded to the latest version yet. But I seriously doubt that Pale Moon has backported every security fix from FF13 and FF14, and if not, it's insecure.

If you don't like the possibility of getting UI changes every six weeks, use Firefox ESR, or, for that matter, use IE. But you're not doing yourself any favors by running an insecure web browser.

it also has the SSE flags set at compile so its snappier than FF

I can't find the benchmarks on the Pale Moon site anymore, but I looked at them some time ago, and didn't observe that it offered any significant performance improvements. I doubt you'll be able to observe a performance difference due to anything other than the placebo effect.

So, here we have Mozilla saying, "porting Firefox to a process (nee thread) model is too hard, but we're going to build an operating system!"

FWIW, most apps in b2g^WFirefox OS will run in separate processes. The difficulty is specifically in porting Firefox to a multi-process architecture; Gecko is pretty capable of working multi-process.

Yet, Chrome continues to grow in market share, for the same reasons as outlined at the start of Electrolysis. In my opinion, the narrative changed but the conditions on the ground did not.

I totally agree. It's possible that the snappy project will get us many of the performance improvements we want without the trouble of electrolysis -- it's hard to say at this point.

I think part of the problem facing WebOS was that they lacked the WebKit expertise necessary to optimize their platform. We at Mozilla do not have the equivalent problem.

Mozilla has such a long history of abandoning [lawrencemandel.com] really good ideas [mozilla.org] when they turn out not to be easy.

[Insert cliche about how if you're going to climb a mountain, you'd better be willing to turn around and run if you encounter a pack of hungry polar bears.]

While you certainly have a point, I think Mozilla gets treated unfairly in this kind of thing. You'll never hear about Apple's failed projects; they might have a much worse history than we do with this sort of thing, for all either of us knows.

FYI, the multithreaded bug has been recently resurrected. I'm still not convinced it's possible, but bhackett is one of the best hackers at Mozilla; if anyone can do this, it's him.

I've seen your name come up (well, I'm assuming it's you based on you Slashdot user)

Yep, same guy. You have me to thank for most of these changes. :)

You mention image.mem.min_discard_timeout_ms. I've already set that one pretty high (1 hour (which really means, 30-90 minutes, right?))

I think it ends up being 1-2hr.

but was wondering if it applies to closed tabs as well as background tabs

As of this bug being resolved, it does not.

Can you describe just briefly what image.mem.max_decoded_image_kb and image.mem.max_bytes_for_sync_decode control?

max_decoded_image_kb is the soft cap on number of bytes that decoded images can consume. We'll try to discard decoded images so we get under this value, with the unfortunate proviso that we'll never discard images on the current tab.

max_bytes_for_sync_decode affects our behavior when decoding previously discarded images. If the image's *compressed* size is less than this value, we'll decode it synchronously. Otherwise we'll decode async. From a practical standpoint, tab switches are blocked until all sync decodes complete, so if you set this too high, you'll observe slow tab switching. If you set this value too low some images may "flicker" into view when you switch tabs.

Fast tab switching is a key goal for us right now, so our plan is to set max_bytes_for_sync_decoded much lower in the near future. (It too is blocked on some stupid things.)

I haven't had much luck finding documentation for these options

Yeah, these prefs are intended to be internal knobs for us to tweak. You're welcome to modify them yourself, but if you notice that Firefox is acting up six months from now, it might be worth resetting them to their default values.