Very exciting. In my view, Firefox Mobile OS has a much better chance of gaining broad adoption than Windows Phone, Blackberry, Symbian, Tizen, and all other non-Android, non-iOS platforms, because its native applications are built with HTML5 and related technologies that have already been embraced by developers worldwide.
From users' perspective, virtually the entire universe of existing HTML5 applications that work on small screens will be native apps for the platform -- from day one.
To anyone who finds this platform compelling and wants to help it to succeed: You can help by writing cross-browser mobile web apps, or by making sure your existing web sites and apps work well in Firefox as well as other browsers. Right now a huge number of mobile sites (including high-profile ones like Google!) use browser-specific code.
And if you are interesting in writing web apps specifically for the B2G platform, check out the new web APIs being proposed and implemented in B2G, and give us feedback on any that you use in your app: https://wiki.mozilla.org/WebAPI
I wish you guys would reconsider your position on mp3 support. We'd love to support mobile Firefox, but without html5 mp3 support, or flash support, that'll be a non-starter until Firefox OS has massive traction, enough to justify the cost of transcoding millions of files and maintaining 2 copies.
Edit: if you're going to down vote please explain why
Yes, there are plans (though not without some controversy) to include H.264 and MP3 decoding at least in B2G (Firefox OS), and possibly on other platforms where they are available from the OS:
I didn't down vote but I guess some readers disagree with your comment. iOS doesn't support flash for some years now. So if firefox OS does too, it doesn't look much like an up hill path.
Ah, to be clear I was asking for MP3 support or flash support, not both (flash support would indirectly mean MP3 support). Essentially to be on par with mobile Safari on the audio front is all I'm really asking. :)
If you want to start testing the Apis you can flash B2G on to a nexus S very easily today. There will be nightly builds available for download soon too if you don't have a build environment set up
A Nexus One? Really? https://developer.mozilla.org/en/Mozilla/Boot_to_Gecko/Setti... suggests that only Nexus S, Galaxy S2, and the Galaxy Nexus are listed. There's also a note that "only devices running Android 4 (aka Ice Cream Sandwich) are supported," where the Nexus One is stuck at Gingerbread.
If this has changed, I'm really, really excited. :)
It's still using Android graphics stack, so it's not that exciting. Tizen at least uses X.org with plans to use Wayland which is the way forward. I hope Mozilla will find vendors to use Wayland for B2G as well. I.e. Android graphics stack (when it's the only option) prevents device from being hackable, i.e. for porting other distros on it (Mer/PlasmaActive, Nemo etc.). Tizen devices with X.org/Wayland drivers will be better in that regard.
On the contrary this is the smartest thing they could have done. GPU h/w acceleration on mobile devices isn't optional
any more and rather than getting mired in the 'real soon now' world of Linux graphics they can get on with the job of producing real and usable devices.
I'm not saying that what they did isn't useful at all. I said it's not exciting, since these upcoming devices will be again Android (compatible) only. Rather boring, but it's not Mozilla's fault, but manufacturers'. They don't produce open specs for their hardware, and don't provide X.org/Wayland drivers either.
We really don't use the Android graphics stack. We use the drivers in the kernel, and we use the gralloc stuff, but that's about it. Everything else is Gecko's own renderer.
(I work on the gfx pipeline for B2G)
Edit: Oh yea, and we use Android's libegl wrapper stuff. Not that it matters, but just in the interest of correctness.
I was primarily referring to the drivers architecture (which is incompatible and useless for X.org and Wayland). I mean in practice, Firefox OS targeted devices won't have X.org/Wayland GPU drivers, only Android ones. It's not important for immediate goals of Mozilla, since squeezing regular Linux graphic drivers from vendors is a horror. But it doesn't help other distros (like Mer/PlasmaActive and etc.), if they decide to make ports to these devices. It may be not Mozilla's primary goal to promote conventional mobile Linux, but in practice these devices won't help that cause (at least for now), so I feel like they won't be enough of "open devices" in that sense.
On the other hand, if X.org/Wayland based devices will appear (like upcoming Mer/Vivaldi tablet), Mozilla can enable B2G to run on them as well, since they'll provide sufficient support for OpenGL ES.
Parenthetically, Google Chrome already has an alpha-quality port to Wayland whereas to my knowledge Mozilla has made no commitment to support Wayland, and no one has started porting Firefox to Wayland.
I may be wrong, but I seem to remember that Tizen HTML5 applications do not use standard HTML5 but rather a non-standard extension. This means that HTML5-for-Tizen applications do not work on, say, an iPhone or an Android device.
By opposition, every application on Firefox OS is based on either standard HTML5 or currently-being-standardized extensions. This means that Firefox OS apps should be cross-platforms.
bergie: my understanding is that Tizen exposes a non-standard mish-mash API and framework (partly based on Tizen's predecessors, Meego and Moblin) to developers -- an approach that isn't really comparable to Mozilla's approach of booting straight into the browser engine, giving developers a fully open, standard browser environment.
In the case of webOS, I am sure: this is not actual HTML 5 but a very specific SDK/framework designed for writing applications specifically for webOS, not for other platforms or the web.
In effect, this means that webOS has almost all the drawbacks of working with HTML5 (no static analysis, performance often difficult to predict, etc.) but none of the benefits (cross-platform, ability to use CoffeeScript or GWT or OCaml or any other language that compiles to JS).
By opposition, Firefox OS apps are cross-platform, can be developed with any tool, etc.
edit Yes, it is possible to write apps using standard HTML5 for WebOS. What is impossible is to write apps using standard HTML5 for WebOS that take any advantage of WebOS (sending SMS, receiving phone calls, etc.). By opposition to Firefox OS, in which even SMS, phone calls, etc. are based on open standards.
Enyo, the framework used for webOS apps seems to now advertise cross-platform support: http://enyojs.com/
Now available for desktop and cross-browser development
- Enyo 2.0 now runs across mobile environments and desktop browsers including Chrome, Firefox, and Internet Explorer
Not only that, but Firefox is a de-facto standard. The HTML extensions adopted by the Firefox Mobile OS team will be not just open, but also widely used from day one -- they will be present in all desktop, tablet, and mobile editions of Firefox across all hardware and OS platforms in which the browser is available.
While these APIs can arguably make some sense on a desktop browser, I get your point that not all capabilities can be cross-platform.
What I was pointing out is that EnyoJS or WebOS or Tizen (afaik) do not make any effort at such portability. Sending a SMS makes as much sense on a WebOS-based device as on an iPhone, an Android smartphone or any other platform. This is one of the key differences between initiatives such as WebOS, Windows 8 or, to a lesser extent, Chrome OS on one side and Firefox OS on the other side. While these OSes offer the features of HTML 5 and some proprietary, non-standardized, non-portable extensions APIs for taking advantage of platform-specific capabilities, Firefox + Firefox OS push to make these capabilities
1/ accessible on all platforms where they makes sense;
2/ standardized so that other browser or os vendors can implement them as they see fit.
The difference is subtle but meaningful. This is the difference between "come and program for my silo platform" and "come and program on everybody's web platform".
Vibration, nothing. Dialing a number or sending an SMS would be sent of to external apps (like Skype), or if none are installed, fail with an error message.
I guess that Vibration webAPI could be implemented on a desktop user agent to activate the vibration of a connected playstation joystick for example, but maybe that's a different API…
> ...but a very specific SDK/framework designed for writing applications specifically for webOS, not for other platforms or the web.
That is incorrect. Apps written for webOS that use the EnyoJS framework are currently seen running on iOS, RIM (Playbook), Android, and even in the Chrome web browser.
Again, correct me if I am wrong, but i believe that these applications cannot send or receive SMS, phone calls, VideoConf calls, using the WebOS APIs on the devices that you describe.
In other words, while EnyoJS may be cross-platform, it represents only a small fraction of the features of WebOS.
But it is still an open source cross-platform HTML5/Javascript based platform. Of course it will not enable you to, for example, send an SMS via an app running in a Chrome web browser, but I would have thought that was a given for any such platform.
To me this is one of the most exciting projects coming up. it is still in early, early days, but it seems to pose the most realistic sane alternative to Android and iOS.
Android is great in that they are open, but their UI library is really just a mess, anybody who uses it for any amount of time yearns for the days of laying things out using HTML. iOS is much better in this respect but has the problem of limited devices and of being a closed platform.
I have no idea how they B2G (Boot2Gecko) will navigate the patent minefield, but I hope they do. I'm picking up another Galaxy Nexus just so I can have a phone dedicated to hacking on it.
I wouldn't bet on it. I have looked at a version of Gaia (Firefox OS's user interface and set of built-in apps) and the apps do not use any specific framework.
While a specific framework enforcing consistency might eventually appear, I do not think that this is the purpose of Mozilla or Firefox OS itself. Probably more the purpose of the companion marketplace.
This is the biggest challenge of building an html5 ecosystem: it is competing with high level, well designed UI abstractions. Help us solve this problem! Mozilla is focusing on the Web Components spec to try and offer a solution https://github.com/mozilla/x-tag
I find B2G very cool, I just hope the underlying stuff for the hardware (drivers; what's called a device tree in the Android world) is all open source or at the very least easily available so that people can easily do their own words.
In other words, I hope Mozilla can strong-arm the hardware partners into actual community-minded open source, rather than whatever the hell Android is doing. (I don't doubt Mozilla here, but their partners.)
It's exciting for developers. The developer build has a "View Source" hard button you can use on any app, so you can view the HTML source on the dialler, home screen, etc.
And maybe for manufacturers too. Some manufacturers are concerned that Android and Windows Phone are becoming more siloed, given the Motorola deal and the MS-manufactured Surface. So the timing might work well for Moz, but like you say, there are patent questions.
This is one of my favorite features.. I know editing on the phone probably isn't realistic, but just that a 'View Source' link is there makes me all warm and fuzzy inside.
I put B2G on my GN and he's right. Once you get into an app there is no way to return to the home screen. You have to pull the battery out and reboot (which, by the way, is the fastest boot I've seen on a smartphone).
Also there are viewport issues with GN. Everything looks zoomed out. Those 2 bugs makes it not really very usable at this point.
I've repeatedly seen HTML5+JS claimed as some kind of panacea for easy, cross-platform application development, but don't really see how it is possible, particularly on mobile devices.
Both the Android and iOS SDKs are pretty specifically optimized for performance on their respective devices, and I don't see the need for those types of optimizations going away anytime soon. As an example, take a UITableView (iOS) or ListView (Android), backed by a SQLite data store that has returned 2000 rows to display.
It's not actually feasible (for performance & memory reasons) to simply render all 2000 rows and allow the user to scroll through them. Instead, both the UITableView & ListView recognize that on a phone, there's only really enough room to display 5-6 rows anyway. So they instantiate those 5-6 rows and populate them with the first few rows from the result set. Then, as the user scrolls down, additional rows can be loaded in, and the previously used rows (that have now been scrolled off-screen) get recycled to represent new rows at the bottom of the table view. Additionally, the data for each row can be loaded on-demand as the user scrolls the row into view, and then be freed once that row has scrolled off screen.
It's a nice and tidy optimization that is absolutely necessary on both platforms (failure to implement the recycling mechanism can basically kill your scrolling performance). That is just one example, there are many more optimizations developers make to keep their apps smooth and responsive on iOS/Android, and a lot of those optimizations involve relatively low-level interaction with the underlying GUI toolkit.
I don't think these types of optimizations are feasible when writing HTML+JS apps, they're simply abstracted too far away from the underlying GUI toolkit. (Some might even say that layer of abstraction is the entire point of using HTML+JS in the first place.) Regardless, I think it severely limits the scope of the types of apps you can create using HTML+JS.
And I haven't even mentioned games, or apps that do any sort of audio/image/video processing. (Even on the web these are often relegated to Flash.)
This scrolling trickery is absolutely doable in html/js. A friend of mine wrote an infinite-scroll table that will handily display tables of tens of thousands of rows. It carefully only requests the right data from the server (with lots of cacheing and prefetching, of course) and only ever instantiates 2*n (n being the number of rows visible) dom elements and just pops them in and out of view.
I think what you are saying that is correct is: UI developers as a general rule do not go to this level of detail, either on web or on native.
But on native, the frameworks have already done these kinds of optimizations for us. I think that's just a matter of the SDKs having more manpower and motivation for making it easy to build apps on their platform.
I actually have a semi-related project right now, so I'm going to go write a Backbone collection smart-scroll plugin that deals with the smart data loading and clever element rejiggering. Thanks for the suggestion.
So as one data point in this comparison, I have a pretty good version of a scrolling grid plugin that swaps in and out existing row dom elements as needed and loads that data dynamically from a backend. It's not totally done and not ready to open-source, but it's generic enough that another day or so of work will make it so.
HN records that my original comment was posted 21 hours ago, and I assure you I spent a good deal of time sleeping and eating inbetween, so this is definitely doable in html/js.
Now, as to the bigger point, that most developers don't know that they should do this to get performance, or that we shouldn't have to write it ourselves, those still stand.
Good point, html5 has some catching up to do here but I think it's possible, at least on JIT'd js environments, to achieve the same performance. Can.js has one of the best performing UI code right now and can do the lazy loading, live binding patterns you're talking about http://canjs.us/
It's absolutely doable in HTML+Js - I've written a TableView in GWT that utilizes the exact same principle and was actually inspired by Cocoa's TableView API. It could render thousands of rows (or however many) utilizing only a few actual divs.
Why do you think this isn't doable in HTML+JS? Seems rather trivial to me. IndexedDB will cover the pagination of large data sets, and removing DOM elements that are out of view is commonly done already.
>Due to the optimization of the platform for entry-level smartphones and the removal of unnecessary middleware layers, mobile operators will have the ability to offer richer experiences ...
So, can we expect that mobile operators and/or manufacturers will yet again put junk on the phones?
Differentiation is a huge selling point for the operators, and will likely remain so as the majority of regular users don't really care about the branding (or, if anything, may feel more secure seeing the operator's logo).
What counts as junk is in the eye of the beholder; the stock ROM that shipped with my Nexus One came with Facebook pre-installed, something that 18 months ago would probably have been seen as a benefit for the average techie nerd type. Thankfully I uninstalled it via Titanium Backup before they rewrote my address book.
I don't see any reason to worry about this, or why it might differ from the Android experience any. If anything, Mozilla is more of a purist company and rules around what may be shipped on a co-branded handset should be a little stricter than what Android had.
However since they are the new entrant, I wouldn't be surprised if they bend over backwards to whore the new platform to the carriers until such times as they have an established market segment with which to negotiate better terms. If this is the case, and the platform is a success, I would count on Mozilla to deliver a purer experience in the long term.
Yup, just like they've been putting junk on the internet. That's what an open platform is like. You can put whatever junk you want in it. Hopefully, one man's junk will be another man's treasure :)
I think they made a mistake to wait this long to do something new and bold, but at least now they are on a solid path.
IMO, their first mistake was not-launching an open source search engine to compete with Google (pre-Chrome era). Second mistake was waiting too long to get this Mobile OS out the door (which is still a ways off it seems).
But this is definitely promising. However, I can't help but wonder about the missed opportunity for collaboration with Canonical. Its clear that Canonical is on a similar mobile trajectory for Ubuntu. An Ubuntu / Firefox Mobile OS would have been cool; and arguably a stronger force to compete against Android/Chrome and iOS.
>they above anyone else were in the greatest position to do it.
Huh? They have been getting most of their revenue from Google. Seems to me they have been among the least able to start a competitor to Google Search because Google can respond by cutting off most of their revenue.
Its true but back in 2008 the contract they had with Google was up for renewal. This was a window of opportunity for Mozilla to make a 'clean break' from Google.
Instead, Mozilla took the money again. And within only a few weeks Google announced Chrome. Convenient timing for Google since the multi-year deal with Firefox was already in place.
So my argument was that back in 2008 Mozilla should have NOT signed any further deals with Google, who was ironically about to become their biggest competitor. Instead, they could have taken the offensive and focused on rolling out a search engine of their own to go toe-to-toe with Google. Of course, its all hindsight now. But at least they're stepping up to the plate now with the HTML5 mobile OS.
You're suggesting that (a) a small company with one big success start a totally new project that requires enormously different skills, and (b) take on Google at their core competency, at the same time? How daft.
Google and Mozilla are not enemies. They are both allies towards an open web. Sure there's the media-hyped browser wars, but Mozilla is about freedom of choice on the web. They are a non-profit who uses Firefox as a playing card in order to further the web. That's how it all started. Microsoft halted development of IE because they saw the web as a threat and Mozilla stepped in. It's never been about the money.
Besides, taking on Google, who accounts for over 90% of Mozilla's cash flow is foolish, especially when Mozilla is a team of 650 and Google is a giant of 30,000 (not to mention in a totally different product). But that's besides the point.
Building B2B on an Android kernel was clever. Mozilla can leverage all the Android hardware support implemented by device OEMs and ongoing kernel maintenance by Google.
While I am exited about this project, I wonder what are actually
HTML5 apps? Where will users get them (will there be some market and who will operate it), will they work online? How are they installed?
There is a marketplace (Mozilla Marketplace, http://marketplace.mozilla.org) already in beta. They work just like regular apps -- HTML/etc, with a JSON "manifest" file that contains metadata.
Disagree. What HTML5 needs is a common set of widgets, usability guidelines, and artwork that make it easy to produce applications that users will enjoy aesthetically and understand how to use implicitly.
The DOM/CSS/JS is a crappy, low-level, do-everything-yourself model for creating applications when compared to the state of the art in native UI/application frameworks. The result is a hodgepodge mishmash of broken, inconsistent application UIs.
Couple that with the inability for any existing browsers' JS runtime to make use of SMP in a single app (despite devices adopting multicore ARM), limited uptake of WebGL, no support for dropping to NEON or even just C (you pay for inefficiency with battery life and poor user experience), etc.
I'd rather see Google produce a NaCL-based set of application libraries that can run on both their Android phones, ChromeOS devices, and our existing desktops. Mozilla's insistence in continuing to invest in pure HTML/JS/CSS is myopic.
The DOM/CSS/JS is a crappy, low-level, do-everything-yourself model for creating applications when compared to the state of the art in native UI/application frameworks.
Well, yes and no. This is a bit like saying that assembly language is a crappy, low-level, do-everything yourself model for creating applications, so that we should not use any language that compiles to assembly language. DOM/CSS/JS are just the brick-and-mortar, there. People are smart enough to build great stuff with them.
Awful stuff, too, of course, but we can just throw it away :)
I think there are at least two problems with using DOM/CSS/JS as building blocks:
1) It discards the network effects/value of having a common, regularly updated platform, shared across all applications.
2) DOM/CSS/JS are terribly inefficient building blocks in terms of processor, memory, graphics. Why waste resources on overly high-level building blocks that we just plan to abstract away.
If those building blocks are going to be abstracted anyway, then maybe we should just skip them. Should we build on top of canvas or WebGL instead?
Apple's accessibility work demonstrates that it is still possible to make native UIs be text-navigable/indexable/structured, which seems to be one of the biggest arguments for keeping the DOM.
Well, your first point is again "let's not use assembly language, it lacks a standard library". Yes, the remark is true, but this just means that we lack higher-level tools above DOM/CSS/JS.
For your second point, I somewhat disagree. JS is now quite efficient. Not CUDA fast yet, sure, but much faster than, say, Python, VB, and often much more memory-efficient than Java. To the point that some video games have been automatically recompiled from C/C++ to JavaScript (through Emscripten) and work quite nicely. Similarly, DOM/CSS are inefficient for really low-level stuff, but suddenly become pretty efficient for animations, for instance.
And, really, the biggest argument for keeping the DOM is not technology, but community: many people know how to use it to do cool stuff.
But yes, canvas + JS or WebGL + JS are also available, for applications that require them.
It's called Twitter Bootstrap. But seriously, there are any number of standard mobile widgets one can use out there from Bootstrap to JQuery Mobile to Sencha touch if all you want is a boilerplate design for app development. I take it you're not a designer, though, because as soon as you want to create applications that don't look like very other app out there you run into the pain of trying to create custom layouts using iOS and Android native development tools. CSS/HTML is far superior, IMO, to the interface tools you get with XCode and the Android Development Tools.
"Any number of" and "standard mobile widgets" makes for an oxymoron.
As for working with designers, no, I'm not a designer, but I find that implementing designs in iOS and Android native tools is far easier than attempting to jimmy HTML+CSS into implementing the behavior and layout as provided by a designer.
In the world of views, I can simply position them where I want and apply arbitrary logic to how they move, scale, etc. This makes it tremendously easier to implement complex designs than straight HTML/CSS.
This looks very interesting, but if I'm reading the w3c proposal correctly, I think the CSS/HTML divide still makes it extremely cumbersome; is there any way for an x-tag to accept an argument that modifies its drawing via CSS?
It was kind of interesting comparing the quotes from the various network operators. For instance, this management-speak gem could apply to any product at all:
"Etisalat aim to enrich the user experience and improve the life of its customers by providing enhanced services across a complete portfolio of devices and operating systems. Firefox OS will provide an open source platform to our customers and various ecosystem players, such as application developers, to experience innovative services. Thanks to this strategic initiative, the industry will benefit from a sustained growth in mobile data and the development of cutting edge applications, as well as the promise of affordable smartphone devices that provide an enriched customer experience."
That digital mockup looks a lot like an iPhone...I'm sure it won't be long before Apple claims that this free software is causing them irreparable harm and moves for an injunction banning anyone from downloading the Mozilla OS or purchasing devices from ZTE.
In this case global support means the multi-national mobile telecoms of industrialized nations. In other words, all the mobile providers scared of a world where Apple, Google, and Microsoft call the shots and squeeze the profit margins that used to be protected by government bandwidth licensing.
On the other hand, I have a hard time comprehending how a platform like Mozilla that's slow enough on desktops can make headway in the mobile space. Clearly WebKit is ahead of the game and is open source as well. I'm reluctantly using Mozilla on the desktop.
HTML5 technology is the future of browsing for sure but lets not turn it into the Java of mobile technology. Native apps have a proper place just by virtue of the performance gains. Putting everything on HTML5 is not only expensive in terms of bandwidth but also processing power, therefore a battery drain. The bandwidth and more importantly the battery are the Achilles heel of mobile.
Also, where does this leave developing countries that are far behind and mainly surviving on WAP phones?
I just find the framing of this press release as nothing but unwarranted hyperbole that is more an corporate alliance where your enemy's enemy is your friend.
I'm a B2G developer and while it's definitely getting close to being usable on a daily basis, there are gaps. Due to the fast pace of development, it's not uncommon that things like the camera or telephony stack will break in an update; we're constantly putting in new optimizations and features, and breaking stuff is okay for us in the short term. Overall, it's pretty damn solid, but expect breakage frequently while things are moving this quick.
I use quite a few, but my primary devices right now are the Galaxy S2 and the Nexus S. I work primarily on the gfx side of things, so I try and test on as many GPUs as I can get my hands on.
I think this is very exciting and I love that they're targeting the cheaper market and also emerging markets where Android, iOS and Blackberry tend to cost too much and Symbian is losing marketshare.
When you say "more convincing" who are you referring to? Remember, the goal here is not a $500 smart phone. The goal is a smart phone that can sell in emerging markets for a price a fraction of what a new iDevice or top-of-the-line Android phone goes for.
It seems likely that an all-HTML OS will be slower than Android, so either Mozilla phones will cost more than Androids or they'll just be slow. I don't see any way to make B2G cheaper than Android, which is already free.
Samsung for instance. They make devices for all price ranges but they have the capability to make really good ones as well. Handsets aren't exactly the strong suit of AlcatelLucent or ZTE.
Mozilla appears to be working on this[0], and improvements are already being seen. (Just as they are vastly improving all the other aspects detractors like to bring up, e.g. memory usage[1], including that of addons via the "Hueyfix"[2].)
This is somewhat of a worry - I love Firefox and use it all the time, but it does freeze up occasionally for a few seconds. Which is acceptable in a browser, but completely useless when making phone calls.
So, one thing that myself and others on the team have been working on is moving things out of the main thread/process. There's a big push by the whole team to get everything working cross-process, so that we can start separate processes for each application; that should let us mitigate the problem of GC pauses and the like. One other big push is making everything off-main-thread composited. That lets the graphics work happen more or less independent of the main thread, and frees it up to do standard processing, in addition to letting animations and the like run async (much smoother).
There's a lot of work still to be done, but those pauses should go away over time.
I should point out that this work is mostly specific to Boot2Gecko. A lot of it is shared with Mobile Firefox, though, and a good bit of it will probably make its way to the desktop eventually as well, but I honestly have no idea on that count (I don't work on Firefox proper).
Quite a lot. I mean, it's the same Gecko core, but there are a lot of pieces to Gecko. Mobile and B2G both use the same EGL backend for gfx, but they use different widgets and some different optimizations (e.g. we know that we have permissions for gralloc on B2G, so we don't use a tiled backend). Desktop and Mobile/B2G share the layout, JS, etc but you've got all sorts of different gfx backends that could be used. Same code, just a lot of divergent pathways.
That is not normal behavior. Have you tried disabling addons to see if that may be the problem? Otherwise I'd suggest trying a new profile (if you've been using Firefox for a long time. Firefox Sync can help you keep your settings as you migrate to a new profile.)
I just diagnosed and fixed a pausing issue with one of my Firefox extensions. The hard part is getting a reproducible case. But once you do, it's usually just a matter of doing a binary search through extensions, enabling and disabling half the candidates until the culprit is found.
A quick verification can be to start Firefox with the -profilemanager flag and create a new profile, and verify if it does or does not occur in a completely fresh profile.
In my case, pauses came from FoxyProxy regular expression pattern matching on urls where I was using:
(.*\.)*
to match subdomains. The issue went away when I did:
(?:.*\.)?
instead - non-capture, and of course noticing that . matched \. too.
I'm fairly sure the boot to Gecko project aims to be agnostic as to what rendering engine is used. IE, you should be able to use a Webkit core instead of a Firefox core.
I would suggest using HP/Palm Luna if you want a webkit-based mobile OS. It's apparently using Qt and should be possible to run it on top of android the same as B2G. If Mozilla's work to standardize the APIs goes well the same apps should be usable on both platforms.
Their idea is that it is an HTML5 standard with some additional Javascript hooks for hardware access, so any browser could be the 'core' with only a few tweaks.
Boot to Gecko / Firefox OS is a Gecko based mobile OS. However, the open apps platform we're building lets you run an HTML5 app on, well, any HTML5 device including Chrome, IE9, etc.
This mostly applies to the Marketplace in how it offers paid apps; we have a decentralized receipt format to let the paid app run on any platform. Unlike any other mobile player, Mozilla is truly making the web the platform. Our platform is not Firefox OS. That's just one device to support open web apps.
From users' perspective, virtually the entire universe of existing HTML5 applications that work on small screens will be native apps for the platform -- from day one.