9 ms·

Mozilla Gains Global Support For a Firefox Mobile OS

313 points by cheeaun 14y ago

aeurielesn 14y ago
I hope the mobile OS doesn't blackout as the Firefox navigator tends to. I lost all hope on Firefox because of this behavior. I don't know if this has been fixed. But anyways, I won't go back to Firefox.
- AndrewDucker 14y ago
  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.
  - gkanai 14y ago
    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.)
    - AndrewDucker 14y ago
      It could be addons. Hard to tell, I'm running several. I haven't recreated my profile in a while, possibly time to give that a go.
      - robin_reala 14y ago
        Before you recreate your entire profile, try the new ‘reset Firefox’ button: https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems https://support.mozilla.org/en-US/kb/reset-firefox-easily-fi...
      - barrkel 14y ago
        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.
  - bmuon 14y ago
    I see that happening to Chrome as well. Freezes for seconds doing intensive hard drive work.
  - daeken 14y ago
    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.
    - AndrewDucker 14y ago
      That's fantastic news. I've been very impressed with the amount of improvements Firefox has been undergoing recently.
      - daeken 14y ago
        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).
        AndrewDucker 14y ago
        I hadn't realised that the codebase was so different. How much code is actually shared between B2G, Mobile and Desktop?
        daeken 14y ago
        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.
- nicpottier 14y ago
  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.
  - khuey 14y ago
    Uh, where did you get that idea from? The rendering engine is even in the name ...
    - tmzt 14y ago
      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.
      - Yoric 14y ago
        ... if HP still exists by then :)
    - nicpottier 14y ago
      Can't find the specific reference now, but seen it mentioned a few times, here's one: http://paulrouget.com/e/b2gdemo/ http://paulrouget.com/e/b2gdemo/ 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.
      - ozten 14y ago
        From your link... "Gecko on top of it. The same version you'll find on a regular Firefox;" Maybe we're confusing web standards with rendering engines, but this is a product with only one rendering engine.
        Yoric 14y ago
- dbaupp 14y ago
  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].) [0]: https://wiki.mozilla.org/Performance/Snappy https://wiki.mozilla.org/Performance/Snappy [1]: https://wiki.mozilla.org/Performance/MemShrink https://wiki.mozilla.org/Performance/MemShrink [2]: http://blog.kylehuey.com/post/21892343371/fixing-the-memory-leak http://blog.kylehuey.com/post/21892343371/fixing-the-memory-...
nicpottier 14y ago
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.
- daleharvey 14y ago
  Right now the Samsung galaxy s2 is your best bet, the lack of hardware keyboard hasn't been accounted for in b2g afaik
  - nicpottier 14y ago
    Really? The GN is listed as one of the supported devices on their page. Would rather drop $350 than whatever an unlocked S2 would cost.
    - MatthewPhillips 14y ago
      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.
  - jsight 14y ago
    I don't understand... the SGS2 doesn't have a hardware keyboard either. Why would it be a better bet?
    - nicpottier 14y ago
      He's talking about the hardware home, back and menu buttons, which the SGS2 has. The GN relies on onscreen buttons only.
justauser 14y ago
Will the Rust Language be a fundamental part of this project?
- joshmoz 14y ago
  Not any time soon. However, presumably if/when our rust-based rendering engine is ready we'll use it for the Firefox OS.
jan_g 14y ago
I am worried by this: >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?
- vibrunazo 14y ago
  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 :)
- forgotusername 14y ago
  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.
- notatoad 14y ago
  you can absolutely expect that. the best we can hope for is that their junk will be easy to rip out of the phones.
- wavephorm 14y ago
  I really hope Mozilla mandates that any such phones will come unlocked, so users can always wipe their phone with a stock B2G.
ozarius 14y ago
This is exactly the kind of push that HTML5 needs to gain a solid footprint., and dev mindshare
- flatline3 14y ago
  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.
  - Yoric 14y ago
    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 :)
    - flatline3 14y ago
      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.
moondowner 14y ago
An exciting development indeed, but I'm afraid what will happen if the phones have bad build quality and how will that affect it's popularity. I've had an Alcatel phone and it's.. I don't know how to say, but Huawei is a better manufacturer than them now, so get the picture.
cs702 14y ago
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.
- bergie 14y ago
  Tizen also uses HTML5 for applications: https://developer.tizen.org/resources/sample-web-applications https://developer.tizen.org/resources/sample-web-application...
  - Yoric 14y ago
    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.
  - j_col 14y ago
    So does webOS, which will be open sourced by HP as "Open webOS 1.0" in September under the Apache license.
    - Yoric 14y ago
      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.
FlyingSnake 14y ago
B2G looks like a viable alternative to Android/iOS. Any information on how stable/usable the B2G project is for daily use?
- Yoric 14y ago
  You can try it :)
- daeken 14y ago
  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.
  - mikeevans 14y ago
    Which phone do you use?
    - daeken 14y ago
      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.
reirob 14y ago
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?
- tree_of_item 14y ago
  https://developer.mozilla.org/en-US/apps https://developer.mozilla.org/en-US/apps
- Yoric 14y ago
  As far as I understand, any combination thereof: - Mozilla has an (open-source, open-standards-based) market technology, that can be deployed both by Mozilla, by operators and by whoever wants to; - any web site could come with the option to install itself as an application, this only requires a few additional files and/or metadata.
- gkoberger 14y ago
  There is a marketplace (Mozilla Marketplace, http://marketplace.mozilla.org http://marketplace.mozilla.org) already in beta. They work just like regular apps -- HTML/etc, with a JSON "manifest" file that contains metadata.
fauigerzigerk 14y ago
I like the idea. I just hope they can get some more convincing hardware partners on board.
- gkanai 14y ago
  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.
  - fauigerzigerk 14y ago
    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.
  - wmf 14y ago
    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.
mrschwabe 14y ago
This is the right strategical move for Mozilla. 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.
- Yoric 14y ago
  IMO, their first mistake was not-launching an open source search engine to compete with Google (pre-Chrome era). Do you have any idea how much it costs to run a search engine? Well, to be true, neither do I, but I am sure that this is a scary amount of money. Plus Mozilla does not have to be (and is not) the only herald of open-source :)
  - mrschwabe 14y ago
    It's true, but they above anyone else were in the greatest position to do it. http://nerdbusiness.com/blog/mozilla-launch-open-source-search-engine http://nerdbusiness.com/blog/mozilla-launch-open-source-sear... Either way, the ship is sailed - DuckDuckGo is now leading the way in this department.
    - hollerith 14y ago
      >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.
      - mrschwabe 14y ago
lalmalang 14y ago
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." [edit: off-topic, i know]
bdg 14y ago
Are we one step closer to the mozilla seabird? http://www.youtube.com/watch?v=oG3tLxEQEdg&feature=youtube_gdata http://www.youtube.com/watch?v=oG3tLxEQEdg&feature=youtu... I wish, but realistically that phone would probably cost $6k today.
cpeterso 14y ago
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.
thechut 14y ago
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. Sarcasm...but just barely
stevenwei 14y ago
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.)
- asolove 14y ago
  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.
anuraj 14y ago
HTML5 enthusiasts - this is your chance (and probably the only one) to prove that it is suitable for mobile. iOS and Android are remaining native.
soapdog 14y ago
OMG! Brazil is going to be first on something tech... so good that I live in Rio!
flocial 14y ago
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.
brackin 14y ago
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.

313 points by cheeaun 14y ago

I hope the mobile OS doesn't blackout as the Firefox navigator tends to. I lost all hope on Firefox because of this behavior. I don't know if this has been fixed. But anyways, I won't go back to Firefox.

AndrewDucker 14y ago
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.
- gkanai 14y ago
  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.)
  - AndrewDucker 14y ago
    It could be addons. Hard to tell, I'm running several. I haven't recreated my profile in a while, possibly time to give that a go.
    - robin_reala 14y ago
      Before you recreate your entire profile, try the new ‘reset Firefox’ button: https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems https://support.mozilla.org/en-US/kb/reset-firefox-easily-fi...
    - barrkel 14y ago
      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.
- bmuon 14y ago
  I see that happening to Chrome as well. Freezes for seconds doing intensive hard drive work.
- daeken 14y ago
  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.
  - AndrewDucker 14y ago
    That's fantastic news. I've been very impressed with the amount of improvements Firefox has been undergoing recently.
    - daeken 14y ago
      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).
      - AndrewDucker 14y ago
        I hadn't realised that the codebase was so different. How much code is actually shared between B2G, Mobile and Desktop?
        daeken 14y ago
        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.
nicpottier 14y ago
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.
- khuey 14y ago
  Uh, where did you get that idea from? The rendering engine is even in the name ...
  - tmzt 14y ago
    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.
    - Yoric 14y ago
      ... if HP still exists by then :)
  - nicpottier 14y ago
    Can't find the specific reference now, but seen it mentioned a few times, here's one: http://paulrouget.com/e/b2gdemo/ http://paulrouget.com/e/b2gdemo/ 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.
    - ozten 14y ago
      From your link... "Gecko on top of it. The same version you'll find on a regular Firefox;" Maybe we're confusing web standards with rendering engines, but this is a product with only one rendering engine.
      - Yoric 14y ago
dbaupp 14y ago
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].) [0]: https://wiki.mozilla.org/Performance/Snappy https://wiki.mozilla.org/Performance/Snappy [1]: https://wiki.mozilla.org/Performance/MemShrink https://wiki.mozilla.org/Performance/MemShrink [2]: http://blog.kylehuey.com/post/21892343371/fixing-the-memory-leak http://blog.kylehuey.com/post/21892343371/fixing-the-memory-...

nicpottier 14y ago

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.

daleharvey 14y ago
Right now the Samsung galaxy s2 is your best bet, the lack of hardware keyboard hasn't been accounted for in b2g afaik
- nicpottier 14y ago
  Really? The GN is listed as one of the supported devices on their page. Would rather drop $350 than whatever an unlocked S2 would cost.
  - MatthewPhillips 14y ago
    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.
- jsight 14y ago
  I don't understand... the SGS2 doesn't have a hardware keyboard either. Why would it be a better bet?
  - nicpottier 14y ago
    He's talking about the hardware home, back and menu buttons, which the SGS2 has. The GN relies on onscreen buttons only.

justauser 14y ago

Will the Rust Language be a fundamental part of this project?

joshmoz 14y ago
Not any time soon. However, presumably if/when our rust-based rendering engine is ready we'll use it for the Firefox OS.

jan_g 14y ago

I am worried by this: >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?

vibrunazo 14y ago
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 :)
forgotusername 14y ago
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.
notatoad 14y ago
you can absolutely expect that. the best we can hope for is that their junk will be easy to rip out of the phones.
wavephorm 14y ago
I really hope Mozilla mandates that any such phones will come unlocked, so users can always wipe their phone with a stock B2G.

ozarius 14y ago

This is exactly the kind of push that HTML5 needs to gain a solid footprint., and dev mindshare

flatline3 14y ago
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.
- Yoric 14y ago
  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 :)
  - flatline3 14y ago
    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.

moondowner 14y ago

An exciting development indeed, but I'm afraid what will happen if the phones have bad build quality and how will that affect it's popularity. I've had an Alcatel phone and it's.. I don't know how to say, but Huawei is a better manufacturer than them now, so get the picture.

cs702 14y ago

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.

bergie 14y ago
Tizen also uses HTML5 for applications: https://developer.tizen.org/resources/sample-web-applications https://developer.tizen.org/resources/sample-web-application...
- Yoric 14y ago
  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.
- j_col 14y ago
  So does webOS, which will be open sourced by HP as "Open webOS 1.0" in September under the Apache license.
  - Yoric 14y ago
    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.

FlyingSnake 14y ago

B2G looks like a viable alternative to Android/iOS. Any information on how stable/usable the B2G project is for daily use?

Yoric 14y ago
You can try it :)
daeken 14y ago
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.
- mikeevans 14y ago
  Which phone do you use?
  - daeken 14y ago
    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.

reirob 14y ago

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?

tree_of_item 14y ago
https://developer.mozilla.org/en-US/apps https://developer.mozilla.org/en-US/apps
Yoric 14y ago
As far as I understand, any combination thereof: - Mozilla has an (open-source, open-standards-based) market technology, that can be deployed both by Mozilla, by operators and by whoever wants to; - any web site could come with the option to install itself as an application, this only requires a few additional files and/or metadata.
gkoberger 14y ago
There is a marketplace (Mozilla Marketplace, http://marketplace.mozilla.org http://marketplace.mozilla.org) already in beta. They work just like regular apps -- HTML/etc, with a JSON "manifest" file that contains metadata.

fauigerzigerk 14y ago

I like the idea. I just hope they can get some more convincing hardware partners on board.

gkanai 14y ago
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.
- fauigerzigerk 14y ago
  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.
- wmf 14y ago
  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.

mrschwabe 14y ago

This is the right strategical move for Mozilla. 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.

Yoric 14y ago
IMO, their first mistake was not-launching an open source search engine to compete with Google (pre-Chrome era). Do you have any idea how much it costs to run a search engine? Well, to be true, neither do I, but I am sure that this is a scary amount of money. Plus Mozilla does not have to be (and is not) the only herald of open-source :)
- mrschwabe 14y ago
  It's true, but they above anyone else were in the greatest position to do it. http://nerdbusiness.com/blog/mozilla-launch-open-source-search-engine http://nerdbusiness.com/blog/mozilla-launch-open-source-sear... Either way, the ship is sailed - DuckDuckGo is now leading the way in this department.
  - hollerith 14y ago
    >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.
    - mrschwabe 14y ago

lalmalang 14y ago

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." [edit: off-topic, i know]

bdg 14y ago

Are we one step closer to the mozilla seabird? http://www.youtube.com/watch?v=oG3tLxEQEdg&feature=youtube_gdata http://www.youtube.com/watch?v=oG3tLxEQEdg&feature=youtu... I wish, but realistically that phone would probably cost $6k today.

cpeterso 14y ago

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.

thechut 14y ago

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. Sarcasm...but just barely

stevenwei 14y ago

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.)

asolove 14y ago
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.

anuraj 14y ago

HTML5 enthusiasts - this is your chance (and probably the only one) to prove that it is suitable for mobile. iOS and Android are remaining native.

soapdog 14y ago

OMG! Brazil is going to be first on something tech... so good that I live in Rio!

flocial 14y ago

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.

brackin 14y ago

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.