Mozilla announces HTML5-based phone

February 29, 2012

This article was contributed by Nathan Willis

Mozilla announced a deal with ~~Latin American~~ mobile carrier Telefónica Digital on February 27 to start shipping HTML5-driven smartphones by the end of 2012. Although the press release dubs the new platform "Open Web Device," many Mozilla watchers know it better as Boot To Gecko (B2G), a lightweight Linux-based system that uses Gecko as its primary (if not sole) application framework. B2G has been in development since July 2011, but it has advanced significantly since we last examined it in mid-August.

B2G architecture

Initially, the project debated several options for the underlying operating system on which to perch the Gecko runtime — including Android (which served as the basis for the earliest experimental builds), MeeGo, and webOS. The team has since settled on an architecture of its own, which takes some components from Android, but constructs its own stack, called Gonk.

Gonk is a stripped-down Linux distribution, using the kernel and some standard userspace libraries for hardware access (e.g., libusb and Bluez). It also borrows hardware abstraction layer code from Android — the architecture document on the Mozilla wiki lists camera and GPS devices in particular. The architecture document also makes references to both the Android kernel and to modified kernels supplied by hardware vendors; evidently B2G is designed to tolerate minor variations.

Gonk also includes an Android-derived init program, D-Bus, wpa_supplicant, and Network Manager. The media playback functionality also comes from Android: there is a mediaserver player for the audio and video formats that Gecko can decode natively, and libstagefright to access binary-only codecs and hardware decoding chips.

Mozilla's B2G team could not be reached for comment, but several of the Android components in the Gonk stack appear to have been chosen for the practical task of bootstrapping the OS on available smartphone hardware (such as the Samsung Galaxy S II, which is the testbed device at Mozilla) rather than on technical grounds. For instance, the setup currently uses Android's Bionic library, but there has been some discussion of replacing it with a more general libc implementation.

Apart from those components and the cellular modem layer, however, Gecko is the only runtime process started. In B2G, there is a master "Gecko server" process named b2g that spawns lower-privileged child processes for each web application run. Only the b2g process can directly access hardware devices; it mediates access requested by the child processes. b2g and the application processes can pass messages to each other using what Mozilla calls "IPC (Interprocess communication) Protocol Definition Language" or IPDL, which originates from the Electrolysis project. Electrolysis is Mozilla's effort to refactor Firefox as a multi-process application; it is still in development, but it provides both synchronous and asynchronous communication, and isolates child processes from each other.

Ultimately, Gonk is different enough from both Android and typical desktop Linux systems to warrant its own build target for Gecko. Among other distinctions, it implements a lightweight input event system, and draws directly to OpenGL ES rather than the X Window system. But in order to provide the full smartphone application framework, the Gecko engine must also have direct access to low-level functionality that is normally handled by other processes — such as the telephony stack.

New APIs

B2G's telephony stack is called the Radio Interface Layer (RIL), and is derived from the corresponding code in Android. RIL caters to device vendors by providing a rilproxy mechanism to manage connections between the b2g process and the cellular modem driver. The driver, called rild, can be proprietary (in fact, the RIL design assumes it is proprietary) and thus link to binary-only firmware blobs without triggering the license inheritance conditions from other parts of the stack.

RIL implements voice and 3G data calls, network status, text and MMS messaging, and SIM card commands (such as storing and retrieving contacts, or entering and validating unlock codes). These commands are exposed to HTML5 applications through the WebTelephony and WebSMS JavaScript APIs, which are still in development.

In fact, much of the B2G-specific functionality requires the definition of new APIs that "traditional" Gecko applications do not expect. Mozilla has already invested in the drafting of OS-independent web APIs for other reasons, including its Web App Store project. Mozilla is also participating in the standardization effort being managed by the W3C, primarily the Device APIs Working Group. At the moment, not every API created by Mozilla has a corresponding W3C specification, although Mozilla says standardizing all of them is the ultimate goal. Mozilla's list includes a mixture of high-level interfaces (such as the Contacts or Camera APIs) and low-level interfaces (such as the Bluetooth and near field communication (NFC) stack APIs).

The most far-reaching APIs in the library are Open Web Apps, which specifies a manifest file format and packaging guidelines for "installable" web applications, and WebRTC, which provides a real-time communication framework used for streaming media as well as network-centric features like peer-to-peer networking. Some of the less familiar specifications under development are APIs for detecting screen orientation, processing notifications when the device is idle, and locking hardware resources (such as preventing screen-dimming).

Applications and interfaces

The plan is for every application in a B2G device to be written in HTML5, CSS, and JavaScript, and naturally the list begins with the generic phone applications: a "home" screen, phone dialer, camera, contact list, calendar, and so on. While phone vendors may prefer to write their own code in-house, Mozilla is at least in the planning and mock-up stage of creating some demo B2G applications.

The demo application suite is code-named Gaia. The wiki page has placeholders for a dozen or so basic applications, including more detailed mock-ups for the web browser, image gallery, and camera application. There are also mock-up images on the Demo page for a home screen, lock screen, and dialer.

More interesting than static mock-ups are the in-development demos found at B2G developer Andreas Gal's GitHub site (screen shots of some are shown here). A recent version of Firefox will open the HTML files from the repository; the homescreen.html file shows the home screen and lock screen, and several other applications are accessible through home screen launchers (the Mozilla wiki's Demo page also links to a "live" demo, but that appears to be out-of-order at the moment). The UI responds to mouse clicks and "slide" gestures, although the applications vary widely in completion, of course — some are just static images. Still, the home screen and generic applications are in place along with basic navigation and UI elements.

The road ahead

The B2G roadmap is ambitious; it predicts a product-ready milestone by the end of the second quarter of 2012. Considering that not all of the fourth quarter 2011 goals have been met yet, that may not be attainable without an infusion of developer time from a hardware partner, but the project did bring a B2G demonstration to Mobile World Congress alongside the February 27 announcement.

Perhaps notably, the Bluetooth, NFC, and USB tracking bugs appear to be behind schedule at the moment, while most of the higher-level work for sensor support and user applications appear to be on track. Arguably the biggest piece of the puzzle yet to get underway is WebRTC support. WebRTC itself is still undergoing rapid development, of course, but without it, the goal of supporting real-time audio and video on a web-runtime smartphone is difficult to imagine.

Resources for potential Open Web Device application developers are also in short supply at the moment. Although Mozilla curates a collection of HTML5 resources at its Mozilla Developer Network (MDN) site, so far only the Open WebApps APIs are covered. Mozilla formally opened its Open Web App "Marketplace" on February 28, in an announcement that referenced the in-progress Web API effort in addition to the traditional desktop platform. That is probably a sign that the Web APIs will make their way to MDN in short order as well.

In its own press release, Telefónica Digital says only that its first Open Web Device-powered phone (which has not been detailed in hardware specification or price) will ship in 2012. That leaves considerable time to complete the project on schedule, although from Mozilla's perspective getting the new JavaScript APIs through the not-known-for-its-rapidity W3C standardization process may be a tight fit.

Index entries for this article
GuestArticles	Willis, Nathan

Mozilla announces HTML5-based phone

Posted Feb 29, 2012 18:17 UTC (Wed) by oniram (guest, #62086) [Link] (2 responses)

Isn't Telefonica a Spanish company?

Mozilla announces HTML5-based phone

Posted Feb 29, 2012 18:51 UTC (Wed) by jake (editor, #205) [Link] (1 responses)

> Isn't Telefonica a Spanish company?

It appears to be a multi-national, but definitely isn't only a Latin American carrier. We updated the article to reflect that.

thanks,

jake

Telefónica Digital?

Posted Mar 1, 2012 8:39 UTC (Thu) by man_ls (guest, #15091) [Link]

Telefónica is a multinational company with headquarters in Spain. Business is primarily done in Europe and Latin America. The most accurate description would certainly be "a Spanish company". Otherwise you might as well say that Google is "a European company".

By the way, Telefónica Digital is not a carrier; it is an internet business owned by Telefónica with interests primarily in Spain, headquartered in London. R&D for the Open Web Device was also done in Spain.

Disclaimer: I own a few Telefónica shares in my ruinous portfolio.

What's the point?

Posted Feb 29, 2012 19:34 UTC (Wed) by khim (subscriber, #9252) [Link] (40 responses)

Can anyone explain what's the selling point of the whole exercise?

It looks to me like some deranged minds are trying to use "web technologies" as a selling point. Gosh. Will they never learn?

Have you really looked on the pitiful history of said technologies? They suck. Big time. Developers don't want them and don't like them.

It's not like this is the first time someone was burned by this fact. In ten years ago Visual Studio .NET (2002) already supported creation of UI in HTML+JScript. Adobe tried (and, of course, failed) the same in 2008 and later Palm decided to use this fallacy for it's own suicide.

You may retort: hey, you don't understand - web technologies are used for complex webapps like Facebook or GMail, they are used to write Firefox extensions - and these are popular too, how can you ever claim they are bad?

Well, this logic sounds solid… if you'll forget that correlation does not imply causation. Yes, in some cases web technologies are widely used. Sometimes immensely so. But what exactly these cases have in common? The answer is easy: in all these cases the odds are severely skewed in favor of web technologies from the beginning. Sure, you can use ActiveX, Java or Flash to implement GMail, but this will lead to severe limitations (for example if you'll want to support things like "Back" and "Forward" browser buttons you'll need serious amount of JavaScript anyway) and reduce number of potential user. The same - with Firefox extensions and in other cases where web technologies are popular choice.

If people have a choice then they prefer to use something else. Even Twitter and Facebook are used almost exclusively via native applications on mobile!

IOW: if you'll push some platform which demands web technologies and this platform will succeed (browsers are major example), then you can make these technologies more popular, but this does not change the fact that people will prefer something else given the chance.

So… what is supposed to attract users and developers to this platform? What they are getting not achievable on iOS or Android? What's the point? Have I missed it somehow?

P.S. The fact that Microsoft has joined the insanity does not change the equation much. On the surface the approaches look somewhat similar, but there are large differences:
1. In reality in Microsoft's case you still can use "good old" C++/C#/etc components and libraries. Only UI must be written in "new, innovative way".
2. Microsoft does have a monopoly on desktop. It can impose "my way or the highway" style transition. Mozilla can't.

What's the point?

Posted Feb 29, 2012 21:25 UTC (Wed) by cmorgan (guest, #71980) [Link] (7 responses)

As a recent (for the past 8 months or so) entrant into development for the web I can say that it has been pretty productive for me. Coming from a c/c++/c# background. Developed an html5/jquery application with background json data refresh that works on iPhone, iPad and PC (haven't tested with Android yet), and that handles screen resizing pretty fluidly.

Maybe the ways you are trying to implement web applications have been the cause of much of your pain. I was using a text editor and chrome's interactive debugger, along with the super helpful jquery toolkit and it was pretty smooth. I abandoned an earlier attempt with GWT because the ui designer for eclipse kept crashing or not rendering things the way I had expected it to, it wasn't worth the hassle of trying to figure it out.

I think companies and developers may have some need for native applications but clearly as the interfaces between the browser and hardware improve and include gps, camera and other interfaces, you'll see a lot more web applications for the simple reason that they deploy/update easily, don't require separate development toolchains, don't need app stores, work across multiple platforms etc.

What's the point?

Posted Mar 1, 2012 5:50 UTC (Thu) by khim (subscriber, #9252) [Link] (6 responses)

As a recent (for the past 8 months or so) entrant into development for the web I can say that it has been pretty productive for me.

I think you missed my point completely… Sigh…

I'll try again.

I'm not talking about the cases where you are forced to use web technologies: it's quite possible to do and if you have no choice (for example if you want to create cross-platform application usable in browser), then it's quite doable.

But if you platform only provides web platform and nothing else then that's liability: it's harder to develop (debugging tools are much less mature, UI creation is convoluted because it was not initially designed with webapps in mind, you can not use threads easily, etc).

I abandoned an earlier attempt with GWT because the ui designer for eclipse kept crashing or not rendering things the way I had expected it to, it wasn't worth the hassle of trying to figure it out.

And this is classic example: where more usable platforms give you a lot of usable choices web platform actually forced you to do everything in HTML/CSS/JavaScript at some point.

Why would anyone choose more limited platform if it s/he can choose richer one?

It's the exact same mistake Sun did (and eventually died because of it): if you offer a platform which makes it possible to write cross-platform applications then said platform may be used by some people (people write lot's of things in Java, right?), but why would anyone use something which only runs such application and nothing else (things like JavaStation)? One may use Windows or Mac, get access to all these applications and to native applications, too.

What's the point?

Posted Mar 1, 2012 17:14 UTC (Thu) by cmorgan (guest, #71980) [Link] (5 responses)

The alternative being to provide another platform with some kind of native support in addition to web technologies? Should it be android, qt, winforms etc? I'm not sure this buys you anything in even the short term of the next few years.

Web technologies are moving fast. It is a compelling argument to develop a web only application to gain cross platform support. The feature sets of web technologies is converging on what is possible with native applications and aiming at where things will be in the next few years seems a better use of effort than providing some other mixed development environment. Nevermind that any apps developed for this platform will work with likely minor changes on all of the other platforms.

Directly towards your point, I'm aware of several companies that are rewriting their native applications for iPhone etc to use web technologies, explicitly because they don't want to deal with multiple platforms. It may reduce the feature set is some cases but it seems pretty clear that the web api is getting closer to native apis all of the time.

What's the point?

Posted Mar 1, 2012 19:23 UTC (Thu) by khim (subscriber, #9252) [Link] (4 responses)

The alternative being to provide another platform with some kind of native support in addition to web technologies?

Before we can discuss path we need to know the destination. What's the goal of the whole excercise?

I'm not sure this buys you anything in even the short term of the next few years.

Long term we are all dead. Battle for the mobile happens here and now. It'll be decided in a next 2-3 years and finished in 5. That's why Microsoft is so desperate: it knows it needs to win in the next few years or else it's toast. Mozilla acts like it has all the time in the world.

Web technologies are moving fast.

Hard to agree here. It took about ten years to finally get 3D (arrived on desktop in 1996, on web in 2007). It still does not support threading (in the era of multicore CPUs!) - and it's not clear if it'll ever will. It's support for legacy libraries is pitiful (yes, you can use emscripten or something similar, but speed, and, more importantly, power consumption will be awful). And so on. It looks like web technologies are moving insanely fast, but that's just because they stagnated for years and now are playing catch up. They are still years behind native.

It is a compelling argument to develop a web only application to gain cross platform support.

Sure. That's because we have no clear winner on mobile: Apple refuses to be it (the old "integrated hardware and software" gambit which failed few times already) and Android have not yet reached critical mass (that's why Microsoft still have a chance).

In times like this "cross-platform solutions" sound good. It was a compelling argument 20 years ago, too. Remember UCSD p-System? Excel used p-code to support both Windows and Mac. In about the same time Windows NT (with support for IA-32, MIPS R3000/R4000, Alpha, PowerPC, Itanium, AMD64 and ARM) was created. Once clear winner formed all these clumsy cross-platform solutions were thrown right out.

Nevermind that any apps developed for this platform will work with likely minor changes on all of the other platforms.

This is key point. Even if some developers will actually switch to web technologies not all of them will do! Thus any platform which supports only cross-platform technologies is at disadvantage by default. If it wants to win it needs something else. It needs it badly! What is it?

Directly towards your point, I'm aware of several companies that are rewriting their native applications for iPhone etc to use web technologies, explicitly because they don't want to deal with multiple platforms.

Sure. It's one way of doing cross-platform development. There are others, as I've pointed out: Qt, SDL, etc. B2G does not support them.

It may reduce the feature set is some cases but it seems pretty clear that the web api is getting closer to native apis all of the time.

Not really. Native is always at least one step (usually two) ahead. Especially when you'll include things like power consumption in the equation (and on mobile you can't ignore it, it's not a desktop and not even a laptop).

Sure, if your application is tied to some other service and noone else can use it (things like Google Maps or some specialized app like bank-client) then you can use web technologies to save the costs. But if it's just an app vs webapp then webapp loses 99% of time (it wins when creator of native app is truly incompetent and just does not know how to write good app).

Android's already won. It's just not apparent yet.

Posted Mar 1, 2012 21:00 UTC (Thu) by rahvin (guest, #16953) [Link] (1 responses)

Sure. That's because we have no clear winner on mobile: Apple refuses to be it (the old "integrated hardware and software" gambit which failed few times already) and Android have not yet reached critical mass (that's why Microsoft still have a chance).

I do not agree. Android has clearly won the battle but with Apple providing a boutique offering. My evidence? Android has already moved into sub $100 phones. There are several android handsets in this range, the most interesting to me is the one with the e-paper screen that has like a week of battery life and is selling like hotcakes in the third world. I fully expect that by the end of next year Android will be in the $20 prepaid dumb phones as well as all the way up to the top end.

You simply can't beat the support for ARM that Linux has and Android benefits from as it's allowing the manufactures to grab source balls and compile a working android install within days of hardware prototyping. There's little reason for them to then build and deploy an alternative OS such as MS or Symbian when almost all the prototyping is being done on Android. The market numbers might not reflect it yet, but Android's clearly won the Mobile OS wars.

Android's already won. It's just not apparent yet.

Posted Mar 8, 2012 12:31 UTC (Thu) by nye (subscriber, #51576) [Link]

>There are several android handsets in this range, the most interesting to me is the one with the e-paper screen that has like a week of battery life and is selling like hotcakes in the third world

Link? That sounds amazing if you can buy it in the UK.

What's the point?

Posted Mar 6, 2012 22:06 UTC (Tue) by roc (subscriber, #30627) [Link] (1 responses)

> It still does not support threading (in the era of multicore CPUs!)

Apart from the internal multithreading of Web browser implementations, there's also Web Workers.

What's the point?

Posted Mar 7, 2012 9:00 UTC (Wed) by khim (subscriber, #9252) [Link]

Yes, internal multithreading of Web browser implementations and Web Workers finally added to the web functionality most other environments offered 15-20 years ago: the ability to run multiple programs truly in parallel. Yahoo! Huge achievement (even if years too late).

This is not comparable to threads, though: you can not process the same piece of data using 4-8 workers (which makes sense if you are working with a single resource-hungry program).

What's the point?

Posted Feb 29, 2012 23:16 UTC (Wed) by kripkenstein (guest, #43281) [Link] (26 responses)

> So… what is supposed to attract users and developers to this platform [web technologies]? What they are getting not achievable on iOS or Android? What's the point? Have I missed it somehow?

One point is that this would be the only mobile OS whose development platform uses standard-based APIs. An example benefit of that is that an "app" for a B2G phone is just a web page (maybe with an app manifest file on the side), so your "apps" can travel with you from mobile phone to mobile phone, and from phone to desktop. With iOS and Android, you can't even transfer apps between them. That's good for developers (sell apps more easily to more people) and users (move apps around).

Yes, there are better (in various senses of the term) development platforms. But none of them are standards-based. By far the best option for a standards-based platform is the web, which is why B2G, WebOS, Tizen, etc. all pick it. Only if you have massive resources to create a new development platform, or already have such a platform, do you not use it (and that is the path Google, Apple and Microsoft have gone). Otherwise, the web is by far the best option.

The web isn't everything, and native platforms are important of course. But we do need to keep some choice open in the market, if the whole mobile market is native apps on iOS and Android, we are in a bad situation. A more open alternative platform like B2G and the web would be a good addition. WebOS would be nice too.

What's the point?

Posted Mar 1, 2012 0:56 UTC (Thu) by Ben_P (guest, #74247) [Link] (1 responses)

Is Tizen based on 'open' +/- API's as well?

Though I haven't seen any hard dates for Tizen phones landing in the US. :/

What's the point?

Posted Mar 1, 2012 1:10 UTC (Thu) by kripkenstein (guest, #43281) [Link]

Tizen was focused on HTML5 too, yeah. However Tizen is being merged with Bada apparently, which is not an HTML-focused platform, so it's not clear what will happen there. Similar merges in the past of mobile OSes with different technology stacks didn't go so well.

What's the point?

Posted Mar 1, 2012 6:33 UTC (Thu) by khim (subscriber, #9252) [Link] (23 responses)

Ohkay… I'll try again…

One point is that this would be the only mobile OS whose development platform uses standard-based APIs.

Well, I'll concede: this is a point. But a hugely negative one at that! When I've asked “what's the point” I kind of expected to see positive point of the whole exercise.

With iOS and Android, you can't even transfer apps between them. That's good for developers (sell apps more easily to more people) and users (move apps around).

I don't even know: to laugh or to cry.
1. You can create iOS app and sell it to [potentially] 250 millions of users.
2. You can create Android app and sell it to [potentially] 150 millions of users.
3. Or you can create "standards-based app" and sell it to [may be] 20 millions of users on desktop, tablets and mobiles.

Do you really believe developers will be excited by the prospect of creating application which covers more platforms and reaches less users? Somehow I doubt it.

Yes, there are better (in various senses of the term) development platforms.

Yup. That's my point. No matter what you choose if you choose anything besides the B2G you'll get more choices! Since B2G only runs standards-based application these applications can be run on other platforms, too (or else how can we say these are standards?) but they can run their native apps in addition to these!

But we do need to keep some choice open in the market, if the whole mobile market is native apps on iOS and Android, we are in a bad situation.

You again got it backwards: I'm not arguing that it's good situation. I'm arguing that it's inevitable situation. If you have no good positive selling points then your platform will fly like a lead balloon (see Windows Phone 7 - but at least Microsoft is trying to attach enough helium to it for a last year and half). And if you have only negative points (like B2G have) then it's not lead balloon anymore. It's balloon made from uranium and if what you are saying is true then Mozilla actively tries to make it more like iridium balloon. This is not a way to win, sorry.

You remind me of Esperantists: they like to preach “bright feature” where everyone will speak Esperanto yet somehow utterly fail to explain just how can we actually reach it. Why will anyone (except few zealots) actually learn it if it'll not help them to do anything “here and now”? “You'll get a lot of advantages if everyone else will do X” is not an argument to do X - it's an argument to skip doing X till “everyone else” will do it. And if most people are not doing X then X will never happen.

What's the point?

Posted Mar 1, 2012 6:48 UTC (Thu) by kripkenstein (guest, #43281) [Link] (17 responses)

>> With iOS and Android, you can't even transfer apps between them. That's good for developers (sell apps more easily to more people) and users (move apps around).

> I don't even know: to laugh or to cry.
> 1. You can create iOS app and sell it to [potentially] 250 millions of users.
> 2. You can create Android app and sell it to [potentially] 150 millions of users.
> 3. Or you can create "standards-based app" and sell it to [may be] 20 millions of users on desktop, tablets and mobiles.

No, iOS and Android can both run web apps. The potential market for web apps is 250M iOS users + 150M Android users + 20M web-based OS users = 420M users (using your numbers). And that's ignoring the web on the desktop.

A web-based OS *does* help right here and right now. Web apps can reach most users, the web is the platform with the most reach of any platform. That's great for developers, who can sell to more users, and also great for users, who can use apps from the device of their choice.

What's the point?

Posted Mar 1, 2012 7:53 UTC (Thu) by khim (subscriber, #9252) [Link] (16 responses)

No, iOS and Android can both run web apps.

Well, kinda. If you squint just right. In both cases webapps are pale shadows of the native apps and it's hard to convince people to use them. They will use them if there are no choice, but given choice they choose native app 9 times out 10.

The potential market for web apps is 250M iOS users + 150M Android users + 20M web-based OS users = 420M users (using your numbers).

Not even close. Most iOS users have visited Appstore. Most Android users have at least opened Android Market once. Yet most Chrome users have not ever opened Chrome Web Store. And I doubt situation will be any different with Mozilla Store. 20M is my rough estimate of all the users who'll visit said store in a year - and it may be too optimistic one.

And that's ignoring the web on the desktop.

20M is mostly from desktop. Users of B2G abomination will be rounding error from this value. Sure, they'll be captive audience and will all visit said store at one point or another, but I don't expect to see more them million or two of them in the first year.

the web is the platform with the most reach of any platform.

True.

Web apps can reach most users

False. Web apps and native apps are very well separated in minds of customers. You can, of course, wrap web apps in some kind of envelope and put it on Android market, but then it'll be perceived as native app - and a poor one at that.

Now, if B2G platform will ever become popular, then this perception may change. But so far all the ideas start with sudden unexplained popularity of B2G platform and I don't foresee where this strange enthusiasm will come from.

What's the point?

Posted Mar 1, 2012 15:54 UTC (Thu) by kripkenstein (guest, #43281) [Link] (15 responses)

> Yet most Chrome users have not ever opened Chrome Web Store

Web Apps != Chrome Web Store. Web apps are just websites, that's all that B2G "apps" are. If you use Chrome or any web browser, you are using "web apps".

The interface for accessing the apps might be more "appy" with the Chrome Web Store". But even without that, websites like gmail are "apps". "Pin as app tab" for example is nothing to do with the Chrome Web Store, but it is "appy".

In fact, the Chrome Web Store doesn't have real websites in it. They can't do stuff normal websites can, for example they can't use Facebook Connect.

What's the point?

Posted Mar 1, 2012 16:16 UTC (Thu) by khim (subscriber, #9252) [Link] (14 responses)

Web apps are just websites, that's all that B2G "apps" are.

I seriously doubt it. If web apps are “just a websites” then why do we need all these new APIs?

But even without that, websites like gmail are "apps".

On mobile? No, they are not. And that's my point: when people are given choice they prefer native applications.

"Pin as app tab" for example is nothing to do with the Chrome Web Store, but it is "appy".

And how many users this feature have? This is genuine question, not a sarcasm. I, personally, know exactly zero real users of said feature, but then, I may be unusual. If you have some statistic then I'd like to hear it.

In fact, the Chrome Web Store doesn't have real websites in it. They can't do stuff normal websites can, for example they can't use Facebook Connect.

So you want to say that Facebook Connect will magically propel Mozilla's store to stardom… hard to believe, but well, it is a point. I doubt it'll be enough to save B2G, though…

What's the point?

Posted Mar 1, 2012 17:55 UTC (Thu) by jmalcolm (subscriber, #8876) [Link]

I do not think this has anything to do with the argument but I certainly use "pin as app tab".

I keep a large number of tabs open and it is wonderful to have a few of them pinned so I can reach them easily. GMail is actually pinned twice for me: once as an email tab and once as my calendar. Sometimes I pin things only temporarily. For example, I might have eBay pinned for a few days if I am on the hunt for something. Some tabs I only pin at work. For example, I do not use Basecamp much on the weekend but I probably use it a few dozen times a day at work.

The last thing I want to do is spend time hunting for a site I use many times a day a moment or two each time. App tabs are an excellent enhancement to my workflow.

What's the point?

Posted Mar 1, 2012 18:00 UTC (Thu) by kripkenstein (guest, #43281) [Link]

>> Web apps are just websites, that's all that B2G "apps" are.

> I seriously doubt it. If web apps are “just a websites” then why do we need all these new APIs?

There are not a lot of new APIs. For something like say Angry Birds, *no* new APIs are needed.

For something that sends SMSes, then the new SMS API would be needed.

But the real point is that these new APIs are going to be in all browsers, they will be standardized as part of the web. (Perhaps with changes, that's how the standards process works.)

>> "Pin as app tab" for example is nothing to do with the Chrome Web Store, but it is "appy".

> And how many users this feature have? This is genuine question, not a sarcasm. I, personally, know exactly zero real users of said feature, but then, I may be unusual. If you have some statistic then I'd like to hear it.

Well, I use it and most people I know. But like you, I don't have statistics. The "pin as app tab" feature is not that important though, it just makes things a little more convenient. Websites are still websites.

> So you want to say that Facebook Connect will magically propel Mozilla's store to stardom… hard to believe, but well, it is a point. I doubt it'll be enough to save B2G, though…

What? No, I just mentioned FC as an example to show that Chrome Web Store apps are *not* normal web pages.

What's the point?

Posted Mar 8, 2012 8:55 UTC (Thu) by kragil (guest, #34373) [Link] (11 responses)

You have very Iphone-loving-first-world POV.(also very skewed)

As I see it B2G is a smart phone platform for very cheap third world phones. By relying on HTML5 only the phones can potentially have fairly low specs and therefore be very cheap. Theoretically the smallest platform for a smart phone is just the browser, because that is the one component you cannot leave out.
Also HTML5 "should" be the safer choice if you don't want to be sued for extortion money from patent trolls like Appl€ and M$ etc.

What's the point?

Posted Mar 8, 2012 9:59 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

As I see it B2G is a smart phone platform for very cheap third world phones.

IOW: for the field which is totally owned by Android today.

By relying on HTML5 only the phones can potentially have fairly low specs and therefore be very cheap.

Well, this remains to be seen. HTML5 technologies are many things, but “low specs” they are not (on desktop you may need ~200MB just to use one complex webapp like GMail). The fact that B2G was demoed on a system with specs identical to HTC Dream (which supported all the latest Android goodies till ICS was released) does not mean finished system will be able to run adequately on such SOC.

And you still need to prove that “obsolete, yet still widely used” Gidgerbread is worse then “brand-spanking new, but empty B2G phone”. Third world may like cheap phones, but it likes Angry Birds as well. Sure, there are HTML5-based one today, but it remains to be seen how many developers will port their goodies to HTML5/B2G (desktop webapps, sadly, are not all that usable on touchscreen device).

Theoretically the smallest platform for a smart phone is just the browser, because that is the one component you cannot leave out.

Have the B2G developers learned nothing? This is repeat of 20 years old battle: while Lotus developers tried to squeeze Lotus 1-2-3 in 640K Microsoft added features to Excel. Two years later Lotus went from “market leader” to “also run”. And B2G is not even a market leader today…

Also HTML5 "should" be the safer choice if you don't want to be sued for extortion money from patent trolls like Appl€ and M$ etc.

Perhaps you meant Oracle? There are more then enough things in B2G-phone for “Appl€ and M$”.

My personal POV: B2G released four years ago (in 2007) had the potential to take the world by storm. Today… the opportunity is just not there anymore.

What's the point?

Posted Mar 8, 2012 12:01 UTC (Thu) by KaiRo (subscriber, #1987) [Link] (1 responses)

As you're getting into specific specs: The devices Telefonica used for their deoms were weaker than those Mozilla used for the demos with Gaia UI (Samsung Galaxy S II in the latter case). Still, all those are of course demo setups and there's a couple of performance improvements still to be made.

That said, Android needs ~300MB for the base system, B2G needs ~100MB. So there's a real chance that B2G can be more performant on low-spec devices than Android.

What's the point?

Posted Mar 8, 2012 12:44 UTC (Thu) by khim (subscriber, #9252) [Link]

That said, Android needs ~300MB for the base system, B2G needs ~100MB. So there's a real chance that B2G can be more performant on low-spec devices than Android.

Android only started requiring ~300MB when nice UI features were added in ICS. You can still run older versions - and they will work just fine.

What's the point?

Posted Mar 8, 2012 11:58 UTC (Thu) by KaiRo (subscriber, #1987) [Link] (7 responses)

The market for rather low-end phones is surely one where we'll see strongly pushed B2G offerings first, due to the engagement of Telefonica, and that's a market where it's surely easier to make a significant impact than on the golden-iCage-loving US high-end market, for example.
But I'm pretty sure that B2G will do well on high-end smart phones and tablet as well technically - the question is if it's possible to make a dent into the current offerings marketing-wise. But perhaps there's three or four people left in the "first world" that care at least a bit about personal freedom and privacy, then it might have some chance with them as well.

What's the point?

Posted Mar 8, 2012 12:58 UTC (Thu) by khim (subscriber, #9252) [Link] (6 responses)

The market for rather low-end phones is surely one where we'll see strongly pushed B2G offerings first, due to the engagement of Telefonica, and that's a market where it's surely easier to make a significant impact than on the golden-iCage-loving US high-end market, for example.

Superconvincing argument. For 2006. Somewhat convincing argument. For 2009. Irrelevant argument. For 2012.

“Low spec” segment you are talking about is not dying. It's already dead. In a world where someone may sell device with 700 MHz processor and 256 Megabytes of RAM for $25 these differences are just not relevant. Pretty soon your basic $30-$50 phone will have SOC with 1GHz CPU and 1GB of RAM - more then enough for any contemporary phone OS. Sure, it'll have crappy LCD and, perhaps, cheap resistive touchscreen, but these things affect Android as much as they affect B2G.

But perhaps there's three or four people left in the "first world" that care at least a bit about personal freedom and privacy, then it might have some chance with them as well.

Oh, sure. There will be hundreds, perhaps thousands of them. Large number but not large enough to justify creation of even a single phone model (see OpenMoko story).

What's the point?

Posted Mar 9, 2012 9:33 UTC (Fri) by kragil (guest, #34373) [Link] (5 responses)

LOL. For really cheap phones every cent matters. An Android phone needs what? 256mb RAM and 512 mb of storage and a 600mhz SOC?
If Mozilla can push these specs down to something like 128 mb RAM, 256 mb of storage and a 400 Mhz SOC it might really have a winner.
I don't believe your 1Ghz, 1GB claim for one second. SOC and RAM prices matter a lot otherwise MS wouldn't have crippled Windows Mobile Phone 7.5 Series Second Enterprise Edition to be able to run on 256mb devices.
Android devices might reach $70 next year (like Eric Schmidt said), but going lower than that is really important for the third world.

A simpler SOC and less storage means lower battery requirement which also lowers the cost. If you build millions and millions of these things every cent matters, no doubt about it.

What's the point?

Posted Mar 9, 2012 11:07 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

For really cheap phones every cent matters.

True. That's why 80% of phones sold in the world today are dumbphones. People just don't buy smartphones if they don't need smartphone capabilities. But if they do then they, of course, will compare price/performance ratio, not just price.

If Mozilla can push these specs down to something like 128 mb RAM, 256 mb of storage and a 400 Mhz SOC it might really have a winner.

Nope. As I've said: in 2006, 2007, may be in 2008 - this will be huge. Today? It's pointless. Most phone SOCs today are designed with Android in mind. Otherwise tens of millions of sales are not guaranteed. And custom chip just for B2G will be more expensive! That's why B2G is trying to piggyback on Android hardware! But if it uses Android hardware then this hardware is android-capable by definition!

SOC and RAM prices matter a lot otherwise MS wouldn't have crippled Windows Mobile Phone 7.5 Series Second Enterprise Edition to be able to run on 256mb devices.

It's matter of timing. If you want to ship device right now, today, then 256MB is somewhat cheaper then 512MB (and 1GB is significantly more expensive), but 128MB make no sense already. Year from now it'll be 512MB for cheapest reasonable option and 1GB will be only marginally more costly. Two (perhaps three) years from now 1GB will be reasonable minimum.

Moore's law makes things cheaper, but it does not mean you can buy cheaper and cheaper chips: manufacturers usually prefer to sell more complex chip for the same (or almost the same) price. And contemporary state-of-the-art processes are incredibly expensive: they can produce very cheap SOCs… but only if you measure quantities in tens of millions. Go to single digit millions - and it's suddenly significantly more expensive, go to hundreds of thousands - and price will go through the roof!

If you build millions and millions of these things every cent matters, no doubt about it.

Sales matter more. If you don't know if you can sell “millions and millions” of these devices then you can get cheap prices only if you are ready to buy tens of millions of SOCs without buyers for the phones. Note that totally cumulative sales of Windows Phone 7 sales are yet to reach 10 million (they are about to cross that line… 1.5 years after start of the sales). Mozilla probably has enough money in bank to try that, but then it'll be stuck with one particular SOC for a long, long time. No a way to win the war.

The times when low spec mattered are long gone. It was important capability 15 years ago (when low-spec PalmOS ruled the PDA world), but today it's no longer a problem to solve.

This concentration on low-spec phones is classic "fight the last war": you can sell existing, established platform using this selling point (that's why Symbian, Samsung Wave and others are still around), but it matters only for large, yet constantly shrinking market which makes it stupid for the new platform development.

What's the point?

Posted Mar 9, 2012 12:32 UTC (Fri) by KaiRo (subscriber, #1987) [Link] (1 responses)

Note that Mozilla is not planning to sell any phones, just working exclusively on the base software stack.

It's partners like Telefonica, Deutsche Telekom, Qualcomm (and a number of others that can't be talked about in public yet) who are planning to sell hardware or devices running a Boot to Gecko stack. And I guess they know those markets better than any of us. I trust them when they are enthusiastic about this stack and say there's a good chance it will be successful.

What's the point?

Posted Mar 9, 2012 13:27 UTC (Fri) by khim (subscriber, #9252) [Link]

It's partners like Telefonica, Deutsche Telekom, Qualcomm (and a number of others that can't be talked about in public yet) who are planning to sell hardware or devices running a Boot to Gecko stack.

Sure. And they will use Android-capable SOCs to do that. Creating some kind of low-spec SOC just for B2G makes no sense at this point.

I trust them when they are enthusiastic about this stack and say there's a good chance it will be successful.

I don't. The problem they face with Android is the fact that it threatens to turn telecoms to “dumb pipes”. Note that about half of revenue in mobile industry comes from voice calls: telecoms will do whatever it takes to protect that. And free, user-controllable handsets threaten their control over these revenues. Thus they want some alternative where they can control the handsets and make sure things like Skype will at least be charged “appropriately”. Mozilla is popular yet it does not have enough resources to threaten their control thus they like it. But I'm doubt they are all that sure B2G will fly: for them it's “yet another bet” - one among dozen or so other bets which are in play. In any case they will cripple the platform to make sure end-user have very little control over the handset: this is what the telecoms usually do, after all.

What's the point?

Posted Mar 9, 2012 13:08 UTC (Fri) by spaetz (guest, #32870) [Link]

khim, can you just give it a rest now? By now we all got your point, and it seems you just can never leave the last word to others. We know you opinion, others are entitled to other opinions. And why should companies such as Telefonica or Deutsche Telekom not be allowed to experiment with alternatives to Android/Windows/iOS ? Following your arguments, one would never have started Linux in 1991 when there were so many established platforms around. And even if B2G fails, but leads to an improved Gecko engine through that, it would be a success in my book. So relax, lean back and see what happens. You can still pull up the "I told you so" card in a few years....

What's the point?

Posted Mar 9, 2012 15:31 UTC (Fri) by kragil (guest, #34373) [Link]

OK, I rephrase(to appease you): IF B2G works (better) on the slowest, cheapest (and still produced) SOCs than Android and manufactures don't have to put in that much storage AND they don't have to pay MS,Apple AND carries will subsidize the phones more(because they can brand them better) THEN B2G might have a chance.
I know that is a lot of IF but it is not unimaginable that B2G might get some traction.

And just for the record: I am not sure it will work. JS+DOM+Web rendering engines right now are not suited for low end devices IMO. In hindsight an open phone based on the enlightenment stack would have been the most promising solution, but I guess nobody was willing to put in the effort to build a Iphone-like experience based on EFL a few years ago. Or they bet on GTK or proprietary shit, which just wasn't good enough.
Nowadays Qt(5) is probably the best solution for an open phone that people actually want to use. Just give people a really open N9 and just be amazed with what they would be able to do.

What's the point?

Posted Mar 1, 2012 17:43 UTC (Thu) by jmalcolm (subscriber, #8876) [Link] (4 responses)

You can deploy HTML5 apps (by which I mean HTML/JavaScript/CSS), such as those made with PhoneGap, to the App Store, Android Market, and others. I do not want to debate the specifics of every case but there is no reason that an end-user even has to be aware that the developer used HTML5 as the platform.

The major advantage of HTML5 is that you only have to write one app. If I launch a start-up that requires mobile client apps I can write a half-dozen clients (one for each platform) or basically just one with HTML5. I might write a native client for my preferred platform and hit the rest with HTML5 even if my long-term strategy is native everywhere. That is simple expediency and management of scarce resources. The broad reach of HTML5 is a major advantage so stop saying it does not have any. For non-mobile apps, the whole fact that you do not have to deploy anything to reach a customer is another simply gigantic win.

I agree that the tools to develop HTML5 are not as mature. They are improving though and you can even get integration local storage, devices like GPS or camera, and other niceties. The whole point of things like B2G and Gaia is to blur the lines between what is possible with HTML5 and native. Not everybody wants to be an innovator but there are some rewards for doing so.

Now, I am not claiming HTML5 is a panacea. I further your point by admitting that, today in mobile, I prefer native apps both as a developer and a user. If I wrote them all, every app might follow this strategy:

http://blog.xamarin.com/2012/02/24/mwc_2012/

I also think that, in general, the best apps will always be native. I think that is possibly part of your point when you say "no good positive selling points" for HTML5. The thing is, there are other ways to differentiate your apps other than using every platform specific feature. Sometimes the differentiation has nothing to do with the app at all. The Kindle app for iPad is HTML5. Not only is it quite good but it would have to be truly terrible not to get used. People use it because they want to use Amazon not because of some exhaustive evaluation of similar apps.

I actually think it is pretty likely that MOST apps might eventually be written in HTML5. Certainly this has already happened on the desktop to a large extent. It will be the one platform pretty much every developer is guaranteed to know and that every device is certain to host. Unless you are doing something special, the question will be why giving up the benefits of HTML5 will be worth going native. The question is not "why HTML5" but rather "why not".

Or not. Time will tell.

What's the point?

Posted Mar 1, 2012 19:50 UTC (Thu) by khim (subscriber, #9252) [Link] (3 responses)

I also think that, in general, the best apps will always be native. I think that is possibly part of your point when you say "no good positive selling points" for HTML5.

Not for HTML5. For B2G. I'm skeptical about the whole HTML5 hoopla, too, but there I can at least see some sense: write once, run everywhere, third time the charm (failure number one, failure number two). Well, may be. Who knows. I'm skeptical, but I see the point. B2G, on the other hand. Nope. Not yet, at least.

I actually think it is pretty likely that MOST apps might eventually be written in HTML5. Certainly this has already happened on the desktop to a large extent.

Hardly. Most desktop applications I'm seeing are written with traditional technologies - be it Civilization V, MS Office 2010 or even MS Visual Studio. XULRunner, Air and others flopped spectacularly. If you are talking about success of in-browser app, then these are popular for totally different reason: this is the way to create of "try-before-you'll-trust-it" application (traditional desktop app can do anything it wants with your computer while in-browser app can be run [relatively] safely even if you don't trust the author). Both Android and iOS offer non-HTML5-based solutions for this problem on mobile this this insanely huge advantage does not exist in mobile world.

Unless you are doing something special, the question will be why giving up the benefits of HTML5 will be worth going native.

What benefits? Try-before-buy is available on mobile without HTML5 inconvenience and as I already wrote history shows that cross-platform solutions remain popular only for a short time till the winning platform emerges.

But well, it's hard to see what happens: perhaps HTML5 will indeed reach critical mass before winning platform will be determined - who knows? The problem: even if I suspend my disbelief and agree to temporarily believe in widespread HTML5 technology adoption (widespread, not ubiquitous! there are a limits for how much I can suspend my disbelief) I still can not see what's the selling point of B2G.

What's the point?

Posted Mar 1, 2012 21:27 UTC (Thu) by kripkenstein (guest, #43281) [Link] (2 responses)

>> Unless you are doing something special, the question will be why giving up the benefits of HTML5 will be worth going native.

> What benefits? Try-before-buy is available on mobile without HTML5 inconvenience

iOS apps are not sandboxed, they are manually inspected by App Store people for malware and so forth. So you do have try-before-buy on iOS, but only because the App Store is curated. And curation is a problem as many developers have found, with Apple reviewers being slow or arbitrary in their decisions. Lack of curation is an advantage of HTML5.

> and as I already wrote history shows that cross-platform solutions remain popular only for a short time till the winning platform emerges.

I would argue the exact opposite. In the beginning, native apps win easily because native app platforms can be created and innovated with quickly. Later, standards-based cross-platform solutions appear, that eventually fill in the gaps between them and native apps, and then the benefits of being standards-based and cross-platform win out.

For example, we all used to use native mail apps once upon a time. Today, most of us use HTML5 webmail.

What's the point?

Posted Mar 1, 2012 22:19 UTC (Thu) by sfeam (subscriber, #2841) [Link] (1 responses)

For example, we all used to use native mail apps once upon a time. Today, most of us use HTML5 webmail.

I'm curious if you have any pointers to data that supports this claim. You may well be right, but I would be a bit surprised. Around here (University environment) nearly everyone uses either a university- or gmail- based mail service. But they use native-mail-app-of-choice via IMAP or Exchange, not a web interface. Or maybe you were only thinking of smart phone Email access?

What's the point?

Posted Mar 1, 2012 22:31 UTC (Thu) by kripkenstein (guest, #43281) [Link]

Well, data is hard to come by, if someone uses "gmail" then I assume they are using the webmail interface, but they can be using it through IMAP and a standalone client. Likewise if someone uses "outlook" then it might be the native client, or it could be the outlook HTML interface.

Personally, I don't think I know anyone that *doesn't* use gmail with it's web interface. The exceptions are yahoo and hotmail, also with their web interfaces.

Best data I can find is that gmail, hotmail and yahoo mail each have >300M users [1]. It's harder to measure usage of native email clients.

http://www.email-marketing-reports.com/metrics/email-stat...

What's the point?

Posted Mar 1, 2012 16:30 UTC (Thu) by gerv (guest, #3376) [Link] (1 responses)

Yes, developers love having to write 3 or more mobile apps whenever they deploy something new. Learning 3 new and different APIs, as well as the web technologies they already know, is a breeze. It's awesome how 30% of the purchase price of their apps goes straight to Apple or Google. They can't get enough of having their apps booted from the App Store for being too similar to Apple's.

What's the problem? Everything in the garden's lovely.

(Have you actually looked at Facebook's "native mobile" application? It's a thin wrapper around a web interface.)

Gerv

What's the point?

Posted Mar 1, 2012 17:39 UTC (Thu) by khim (subscriber, #9252) [Link]

Underpant Gnomes, repeat number 1001. You've explained very well how much profit everyone will get when B2G will replace everything. But I'm asking about item number 2: the one which goes after #1 “Collect Underpants”^W“Create B2G” and #3“Profit”^W“Celebrate the victory of web technologies”.

Yes, developers love having to write 3 or more mobile apps whenever they deploy something new. Learning 3 new and different APIs, as well as the web technologies they already know, is a breeze. It's awesome how 30% of the purchase price of their apps goes straight to Apple or Google. They can't get enough of having their apps booted from the App Store for being too similar to Apple's.

You assume:
1. Everyone knows "web technologies" (while in fact they are quite new, immature and thus knowledgeable programmers demand premium prices).
2. The only way to write cross-platform application is to use said "web technologies" (while in reality threre are many ways to build cross-platform application for different mobile platforms. SDL, Qt, other, more specialized, toolkits (like Unity 3D for games).

(Have you actually looked at Facebook's "native mobile" application? It's a thin wrapper around a web interface.)

Actually it includes quite a few native controls, but yes, this approach makes sense if you already have a webapp. But my question is about B2G: what can convince users to switch to the platform which has access to the small pile of apps when it can buy other platforms which have much larger selection.

Developers will write applications for the platform if they can sell them (directly or using embedded ads). They may not like to write half-dozen different versions (for iOS, Android, WP7, BlackBerry, Bada, etc), but they will do that if users will be there. What they will not do is to write apps which can not be sold. Well, some will decide that it's easier to just write webapp and wait till “inevitable B2G victory” will do the rest, but natural selection will eliminate these pretty fast.

What's the point?

Posted Mar 1, 2012 23:14 UTC (Thu) by dgm (subscriber, #49227) [Link] (1 responses)

According to a local newspaper, the main point is that it will enable a new line of very cheap smartphones, the price point being about just 50€ (65$).

What's the point?

Posted Mar 9, 2012 12:26 UTC (Fri) by steffen780 (guest, #68142) [Link]

If that's the motivation then Telefonica is pretty crazy. I got two Android phones at <70€ each - incl. shipping - as birthday presents in October. Seems the cheapest now is 72€ (excl. shipping) but I'd be very surprised if Android phones aren't available for ~50€ by the time B2G is ready to sell.

What's the point?

Posted Apr 2, 2012 9:34 UTC (Mon) by ceplm (subscriber, #41334) [Link]

> Can anyone explain what's the selling point of the whole exercise?

http://joelonsoftware.com/articles/APIWar.html

Notice, that if you were follower of the official Nokia APIs of the last fashion, and if the rumors about WP8 being incompatible with WP7 are true, then you are on fifth API in five years. Fun!

Mozilla announces HTML5-based phone

Posted Feb 29, 2012 23:07 UTC (Wed) by kripkenstein (guest, #43281) [Link] (13 responses)

> Electrolysis is Mozilla's effort to refactor Firefox as a multi-process application; it is still in development, but it provides both synchronous and asynchronous communication, and isolates child processes from each other.

Minor note: Electrolysis works and has been complete for a while now. Firefox Mobile used it last year, for example. It isn't used on Firefox desktop because it would break too many addons, not because it isn't ready.

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 14:58 UTC (Sat) by Tet (subscriber, #5433) [Link] (12 responses)

It isn't used on Firefox desktop because it would break too many addons, not because it isn't ready.

That doesn't make sense. Firefox already breaks addons every couple of months anyway. Indeed, they so frequently ignore backward compatibility that I'd started to assume it was a deliberate policy.

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 17:06 UTC (Sat) by kripkenstein (guest, #43281) [Link] (11 responses)

FF10 defaults addons to compatible, and the % of incompatible addons has been decreasing with each release. But a split-process model would break most addons, with no fix but rewriting them.

FF mobile and B2G FF use the split process model, though (addons are less of an issue there).

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 18:14 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

So no plans for Firefox to ever move to a split process model on the desktop?

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 18:43 UTC (Sat) by kripkenstein (guest, #43281) [Link] (9 responses)

It's still being investigated, there might be some way to get some addons to work automatically even in a split-process model. But it won't be anytime soon.

Of course someone can fork Firefox right now and enable the split-process model, almost all the work for that has already been done. You can also run Mobile Firefox on your desktop, with a split-process model (but the UI is optimized for tablets).

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 18:57 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (8 responses)

Couldn't it be a config option for users who don't care about add-ons much? That would be a step forward.

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 19:00 UTC (Sat) by kripkenstein (guest, #43281) [Link] (7 responses)

It's not a simple flag to switch, you need to build separate executables for the parent and child processes. So it would require a separate build.

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 19:50 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

I think I was not clear enough. If Firefox could move to a stage where it is a simple flag, that would help test this feature more and perhaps eventually move into a split process model for desktop as well. I think there are significant advantages in doing so.

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 19:57 UTC (Sat) by kripkenstein (guest, #43281) [Link] (5 responses)

I agree, that would be useful. It would be hard to achieve though, currently you build Firefox in either single-process or split-process mode, and that makes a lot of difference in the generated executable(s).

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 22:51 UTC (Sat) by dlang (guest, #313) [Link] (4 responses)

so why could you not offer both options?

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 22:54 UTC (Sat) by kripkenstein (guest, #43281) [Link] (3 responses)

Another download option means double the build infrastructure load and double the QA effort.

Doing this halfheartedly is easy, while doing this properly is very hard. I don't think Mozilla would do this halfheartedly, properly is the only option. But again, anyone can fork that code and do it halfheartedly if they so choose.

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 22:59 UTC (Sat) by dlang (guest, #313) [Link] (2 responses)

for a long time the 64 bit linux support was 'halfhearted' by your definition.

even if it's a halfhearted effort with just the builds, but without the in-house QA efforts, users can try it and report where it does and doesn't work.

as for the load on the build servers, I don't buy that as a limiting factor, builds are done frequently, but not continuously, and I've seen people talking about process changes for firefox development that would raise the frequency of builds by several orders of magnatude without any outcry about the massive new datacenter that would be needed to hold all the new build servers that this would require.

Mozilla announces HTML5-based phone

Posted Mar 3, 2012 23:04 UTC (Sat) by kripkenstein (guest, #43281) [Link] (1 responses)

Yes, the 64-bit support is indeed halfhearted. But it is done as part of the process of making them formally supported, which isn't currently the case with multiprocess builds (there is no plan for making them supported).

I agree about the build servers, that's less of an issue, the main problem is QA effort which is already maxed out.

Mozilla announces HTML5-based phone

Posted Mar 4, 2012 1:05 UTC (Sun) by KaiRo (subscriber, #1987) [Link]

For one thing, Firefox 64bit support is not halfhearted at all for Linux and Mac, but fully and officially supported (Windows is a different story).

For the other, split processes are still in the plans but postponed indefinitely while other ways of making the UI more responsive are being prioritized - Mozilla simply doesn't hve the manpower to do everything at once. The problem also isn't just add-ons but also that a lot of current Firefox UI has to be rewritten to communicate / react to website content asynchronously and indirectly, which it doesn't do right now.

Basically, it all comes down to being a lot of work, and a ton of QA and the manpower needed for this currently is being spent on things that are deemed higher priority like making the UI snappy to react in other ways. Volunteers doing work on achieving split processes sooner are of course welcome. It's not as simple as a switch though, there's a lot of work to be done before such a switch would leave even the current Firefox UI reasonably working.

Using split processes is much easier for something rewritten from scratch like the XUL (tablet) UI for mobile devices or - what this article is about actually - Boot to Gecko.

Mozilla announces HTML5-based phone

Posted Mar 1, 2012 1:18 UTC (Thu) by paravoid (subscriber, #32869) [Link] (9 responses)

As a free software enthusiast, I have mixed feelings about this.

On one hand, it's Mozilla that we know and love, it's free software and it's an effort driven by a community project and run by that.

On the other hand, the platform not only seems to accept proprietary components (like rild) as a compromise, but even embraces them and tries to actively support closed source components (the bug report about the libc counts the fact that uClibc & (e)glibc are GPL'ed as a disadvantage!). Additionally, it speaks about an "open platform", as in the Web, with open standards and all that, which of course says nothing about the freeness of such (Web) applications or reassures me about preserving my essential freedoms. Not unlike Android, but a big difference with free operating systems and platforms that most people around LWN are accustomed to.

All in all, it seems to me as an effort to build a proprietary platform with a free software layer between closed-source components and well-defined APIs to interface between them. What's the point? We already have Android for that, what we really need is a *more free* platform!

Mozilla announces HTML5-based phone

Posted Mar 1, 2012 5:12 UTC (Thu) by kripkenstein (guest, #43281) [Link] (6 responses)

> All in all, it seems to me as an effort to build a proprietary platform with a free software layer between closed-source components and well-defined APIs to interface between them. What's the point? We already have Android for that, what we really need is a *more free* platform!

This platform is more open than Android. First and foremost, development is done in the open, not in the form of code drops like Android does. Participation in development is open just like regular open source projects. Second, the platform is built on open standards, not proprietary ones. Open standards aren't the same as open source, but both are important.

There are compromises though, like the ability to interface with binary blobs on the device, like Android does. I don't like this either, but without that it would be much, much harder to get device manufacturers and carriers on board. Is this the right amount of compromise, that keeps the platform open while allowing it to succeed, without giving up too much? Time will tell. But it's significantly more open than Android, that much is already clear.

Mozilla announces HTML5-based phone

Posted Mar 1, 2012 11:29 UTC (Thu) by alankila (guest, #47141) [Link] (4 responses)

I think the strategy is a sound one. Piggybacking on android should allow this OS to become an aftermarket OS choice for a number of phones, and will indeed make it easier to ship in place of Android out of the box, too. I have nothing against web applications as the primary way applications get made on an operating system, but it seems to me that support for HTML5 is still lacking and the APIs for all the hardware on tablets and phones are either not there or not implemented the same way, or whatever. WebGL support, for instance, would be very welcome.

Mozilla announces HTML5-based phone

Posted Mar 6, 2012 22:11 UTC (Tue) by roc (subscriber, #30627) [Link] (3 responses)

B2G supports WebGL. It also supports new Web standard APIs for features like fullscreen, battery, and so on.

Mozilla announces HTML5-based phone

Posted Mar 7, 2012 9:04 UTC (Wed) by khim (subscriber, #9252) [Link] (2 responses)

B2G supports WebGL, but most other phone platforms don't. This makes it non-standard feature as far as developers are concerned.

The fact that you have “standard” stamp from W3C or IETF does not make your platform the default choice for developers. Think desktop: POSIX is standard and Win16 is too while Win32 is non-standard, but how many developers develop for POSIX and/or Win16 and how many develop for Windows?

Mozilla announces HTML5-based phone

Posted Mar 7, 2012 11:35 UTC (Wed) by anselm (subscriber, #2796) [Link]

B2G supports WebGL, but most other phone platforms don't. This makes it non-standard feature as far as developers are concerned.

WebGL is essentially OpenGL ES 2.0, which all mobile platforms worth mentioning do support. There are various web browsers with WebGL support for Android, and WebGL can apparently be made to work on iOS, too. Not exactly non-standard.

Mozilla announces HTML5-based phone

Posted Mar 7, 2012 16:25 UTC (Wed) by kripkenstein (guest, #43281) [Link]

> B2G supports WebGL, but most other phone platforms don't. This makes it non-standard feature as far as developers are concerned.

WebGL is certainly a standard. It's just a new one, it will take time for everyone to implement support. But they will catch up to B2G and do that.

Mozilla announces HTML5-based phone

Posted Mar 4, 2012 7:26 UTC (Sun) by tajyrink (subscriber, #2750) [Link]

As long as the proprietary components are clearly defined and separated, it's fine. Not fine as "really fine", but certainly an acceptable compromise if it allows for success in vendor and consumer reach this year and not in five years.

When not fixing all the problems at once, it's good that at least more problems aren't created.

Mozilla announces HTML5-based phone

Posted Mar 1, 2012 13:01 UTC (Thu) by samth (guest, #1290) [Link]

Even apart from the technical details (which kripenstein describes), when you watch the demo videos, you can see them show off the "View Source" button for the user interface. All by itself, that's a big sign of how open this is.

Mozilla announces HTML5-based phone

Posted Mar 1, 2012 16:25 UTC (Thu) by gerv (guest, #3376) [Link]

It would be nice to fix ALL THE PROBLEMS at once, but I think to begin with we might just settle for fixing several big ones, at which other companies have already failed. :-)

If B2G required every bit of software right the way down to be open from the start, it would never ship a phone and therefore have zero market impact. The fact that some bits of the stacks of some phones will be proprietary doesn't mean we think this is a good thing, or that we won't be using various means to try and improve matters.

Gerv

Carriers will love this

Posted Mar 1, 2012 1:43 UTC (Thu) by aryonoco (subscriber, #55563) [Link] (8 responses)

B2G is a very interesting concept, and it takes the concept of Web apps to a whole new level. It's important to note that Mozilla wants to standardise these APIs, and then hopefully other browser makers on other mobile platforms can implement these APIs in their browsers as well, which would open up a whole new level of opportunities for developing cross platform apps.

Being totally written in HTML and Javascript means that carriers will absolutely love this. I know many carriers want to have more say on their devices, and they absolutely hate how iOS and Android are turning them into dumb pipes.

Have a look at a demo here at MWC. I actually think the progress that Mozilla has made in such a short amount of time is astounding.

http://www.youtube.com/watch?feature=player_embedded&...

The Verge also has good coverage: http://www.theverge.com/2012/2/27/2827659/mozillas-boot-t...

Carriers will love this

Posted Mar 1, 2012 6:49 UTC (Thu) by khim (subscriber, #9252) [Link] (6 responses)

I know many carriers want to have more say on their devices, and they absolutely hate how iOS and Android are turning them into dumb pipes.

Well, that's natural progression. ISPs already went through this (remember CompuServe and AOL?), and it's obvious carriers will [eventually] follow. We are still far, far away from that point in US (but some other countries are further along: there are lots of countries where the idea that carrier may sell you a phone is met with bewilderment). But can you explain exactly how carriers can turn the wheel of history back with B2G? What can they do with it that they can't do with Android, for example?

Carriers will love this

Posted Mar 1, 2012 16:27 UTC (Thu) by gerv (guest, #3376) [Link] (1 responses)

> What can they do with it that they can't do with Android, for example?

Ship it without being bound by a partnership agreement with Google or, alternatively, with a 6 month time-to-market delay.

Gerv

Carriers will love this

Posted Mar 1, 2012 17:02 UTC (Thu) by khim (subscriber, #9252) [Link]

Point. Of course for that to be viable advantage B2G should provide something at least comparable to six-month-old Android.

Carriers will love this

Posted Mar 3, 2012 2:19 UTC (Sat) by KaiRo (subscriber, #1987) [Link] (1 responses)

One thing to note is that Mozilla is trying hard in B2G to make sure nobody but the user has full control over the device - that is at least as far as the law permits (phones e.g. have to have a fixed dialer UI that is vetted to always allow emergency calls, so unfortunately the dialer cannot be exchangable by law in most countries).
Interestingly, the nice side-effect of that user control is that the one selling the device to the user has control over the default configuration they sell it with (and the configuration they deliver support for) and that's what the carriers like as that is usually them and so they can distinguish their offer.

Carriers will love this

Posted Mar 3, 2012 12:13 UTC (Sat) by khim (subscriber, #9252) [Link]

One thing to note is that Mozilla is trying hard in B2G to make sure nobody but the user has full control over the device - that is at least as far as the law permits (phones e.g. have to have a fixed dialer UI that is vetted to always allow emergency calls, so unfortunately the dialer cannot be exchangable by law in most countries).

This is certainly an advantage, but how many will actually care? Android already offers something like this with Nexus line and it's not overwhelmingly popular. I think the current Android's compromise (you have locked device for the duration of your warranty and you have unlocking tool which voids said warranty and thus used after it expires as an insurance tool) is “good enough”. Most users prefer having Netflix to having full control over device. This is sad truth, but still a truth.

Interestingly, the nice side-effect of that user control is that the one selling the device to the user has control over the default configuration they sell it with (and the configuration they deliver support for) and that's what the carriers like as that is usually them and so they can distinguish their offer.

Perhaps you are talking about some alien carriers from the other galaxy. Carriers from this planet like to have tight control over sold handset, too (for example they usually try to suppress free tethering programs). If B2G places control firmly in the hands of user then they will hate it. But in reality I think carriers will subvert the B2G phones like they subverted Android phones - which will mostly negate previous advantage.

Carriers will love this

Posted Mar 6, 2012 22:32 UTC (Tue) by roc (subscriber, #30627) [Link] (1 responses)

One difference between Android and B2G is that, if you're browsing the Web or using an HTML-based app (e.g. written with PhoneGap) on Android, you're running two software stacks at once:
-- a Web stack: Javascript VM + CSS + HTML + ...
-- an Android stack: Java VM + Android Java frameworks

With B2G you only run the Web stack. It's a footprint win.

(iOS also has a two-stack problem.)

Carriers will love this

Posted Mar 7, 2012 9:13 UTC (Wed) by khim (subscriber, #9252) [Link]

One difference between Android and B2G is that, if you're browsing the Web or using an HTML-based app (e.g. written with PhoneGap) on Android, you're running two software stacks at once:
-- a Web stack: Javascript VM + CSS + HTML + ...
-- an Android stack: Java VM + Android Java frameworks

With B2G you only run the Web stack. It's a footprint win.

And again you are talking about “bright future” where everyone abandoned native applications and switched to web applications exclusively. How do you plan to reach this future?

Yes, today B2G may be a win for a small percentage of the applications which are written using web technologies, but most applications don't need them and for them it's a loss: you need to run two stacks on B2G:
— Javascript VM + CSS + HTML + …
— emscripten + framebuffer-emulator-top-of-canvas + …

Significant additional footprint + additional work for obscure unpopular platform.

Carriers will love this

Posted Mar 1, 2012 11:34 UTC (Thu) by alankila (guest, #47141) [Link]

Yeah, I think having just a well-defined set of APIs is enough. Suppose B2G comes with API definition, and some good applications written with it: both iOS and Android can use native bits to enhance built-in javascript functionality, so provided that the APIs are not too demanding to support, a compatibility glue layer to make B2G applications work on iOS and Android should be possible.

After that, it's just up or the platform vendors to natively support B2G, so that the compatibility layer can be shrunk and dropped eventually. But if they don't do this, it doesn't really matter: the application is there and will work anyway. That's the theory, anyway.

Mozilla announces HTML5-based phone

Posted Mar 1, 2012 17:20 UTC (Thu) by angdraug (subscriber, #7487) [Link] (1 responses)

I hope it's not real phone numbers of real people on that screenshot...

Mozilla announces HTML5-based phone

Posted Mar 1, 2012 18:05 UTC (Thu) by jmalcolm (subscriber, #8876) [Link]

The 555 area code is often used in movies and in marketing material to display fake phone numbers.

Mozilla announces HTML5-based phone

Posted Mar 10, 2012 2:12 UTC (Sat) by Fowl (subscriber, #65667) [Link]

I wonder if they have an update strategy. That is, what motivation is there for carriers and manufactures to provide them? Many of the problems with the mobile web relate to the fact that we have millions of point in time snapshots of Webkit out there that will *never* be updated - not just bad for security but for moving forward too.

Mozilla announces HTML5-based phone

Posted Mar 20, 2012 15:17 UTC (Tue) by stock (guest, #5849) [Link] (1 responses)

If the devil were to bring the system down, where would it manifest itself ?
The gcc or the firefox department ?

As many of you adorate Linux desktop users have noticed, be it ubuntu,
kubuntu, Mandriva, OpenSuSE, or even Mac OSX, is that a run-away
version fire, of firefox versions, has started at the mozilla
development campus. Some analysts have already rumored that this is not
just any version pyre, but it has all the aspects and phenomena of a
incendiary fire, i.e. an act of arson. I came across this when trying
to compile firefox version 3.6.24 myself on a freshly installed
Mandriva 2011 desktop, which has the latest and greatest KDE Desktop
Version 4.6.5.

What one then does is download firefox-3.6.24.source.tar.bz2 and
firefox-3.6.24.source.tar.bz2.asc from :

ftp://ftp.mozilla.org/pub/firefox/releases/3.6.24/source/...
ftp://ftp.mozilla.org/pub/firefox/releases/3.6.24/source/...

When unpacking the tar.bz2 ball it creates a directory xulrunner-1.9.2,
which actually should have been named xulrunner-1.9.2.24, as a close
inspection of xulrunner-1.9.2/config/milestone.tx will show you :

# Holds the current milestone.
# Should be in the format of
#
# x.x.x
# x.x.x.x
# x.x.x+
#
# Referenced by milestone.pl.
# Hopefully I'll be able to automate replacement of *all*
# hardcoded milestones in the tree from these two files.
#--------------------------------------------------------

1.9.2.24

firefox-3.6.24 is built from this source tree in a two step compile
process. The first thing one does is to create the xulrunner
development layer by activating --enable-application=xulrunner in the
configure run :

xulrunner-1.9.2-0.3-mdv2011.0.x86_64.rpm
lib64xulrunner-1.9.2-0.3-mdv2011.0.x86_64.rpm
lib64xulrunner-devel-1.9.2-0.3-mdv2011.0.x86_64.rpm
xulrunner-debug-1.9.2-0.3-mdv2011.0.x

after which, firefox-3.6.24-0.3-mdv2011.0.x86_64.rpm is created from
a second compile run by activating --enable-application=browser, which
needs the freshly created xulrunner-devel packages to successfully compile.

No surprise, my problems already started with the first step, the creation
of the xulrunner development gear :

" c++ -o nsID.o -c -I../../dist/system_wrappers -include ../../config/gcc_hidden.h -DOSTYPE=\"Linux2.6.39.4-4\" -DOSARCH=Linux -DTARGET_XPCOM_ABI=\"x86_64-gcc3\" -I./../build -I. -I. -I../../dist/include -I../../dist/include/nsprpub -I/usr/include/nspr4 -I/usr/include/nss -fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -O2 -g -frecord-gcc-switches -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all -fPIC -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions -DMOZILLA_CLIENT -include ../../mozilla-config.h -Wp,-MD,.deps/nsID.pp nsID.cpp
nsEnumeratorUtils.cpp:115:27: error: uninitialized const 'EmptyEnumeratorImpl::kInstance' [-fpermissive]
nsEnumeratorUtils.cpp:50:7: note: 'const class EmptyEnumeratorImpl' has no user-provided default constructor
make[4]: *** [nsEnumeratorUtils.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory `/root/rpmbuild/BUILD/mozilla-1.9.2/xpcom/glue'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/root/rpmbuild/BUILD/mozilla-1.9.2/xpcom'
make[2]: *** [libs_tier_xpcom] Error 2
make[2]: Leaving directory `/root/rpmbuild/BUILD/mozilla-1.9.2'
make[1]: *** [tier_xpcom] Error 2
make[1]: Leaving directory `/root/rpmbuild/BUILD/mozilla-1.9.2'
make: *** [default] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.80949 (%build)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.80949 (%build)
[acer30:root]:(~/rpmbuild/SPECS)# "

Inserting this error

nsEnumeratorUtils.cpp:115:27: error: uninitialized const 'EmptyEnumeratorImpl::kInstance' [-fpermissive]

into google.com brings me to the following bug report ref. {1} :

"FS#23463 - [gcc 4.6] xulrunner cannot be built using gcc 4.6

Attached to Project: Arch Linux
Opened by Frederic Bezies (fredbezies) -
Sunday, 27 March 2011, 06:26 GMT-4
Last edited by Andrea Scarpino (BaSh) -
Saturday, 16 April 2011, 06:57 GMT-4

Details
I wanted this morning to build an homemade version of mozilla
minefield, using trunk source code as I do everyday or so.

But since I installed gcc 4.6 using testing repository, I cannot
get it to be built. So I reported the bug on mozilla bugzilla,
cf https://bugzilla.mozilla.org/show_bug.cgi?id=645469 [ref. {2}]

I wanted to verify if it was related to gcc 4.6 at all.

So, after cleaning ccache cache, I grabbed xulrunner tarball,
and launch build process using makepkg.

And it won't work. Here is the error log :

c++ -o nsWeakReference.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include /home/fred/xulrunner/src/mozilla-2.0/config/gcc_hidden.h -DOSTYPE=\"Linux2.6\" -DOSARCH=Linux -DTARGET_XPCOM_ABI=\"x86_64-gcc3\" -I/home/fred/xulrunner/src/mozilla-2.0/xpcom/glue/../build -I/home/fred/xulrunner/src/mozilla-2.0/xpcom/glue -I. -I../../dist/include -I../../dist/include/nsprpub -I/usr/include/nspr -I/usr/include/nss -fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fomit-frame-pointer -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MF .deps/nsWeakReference.pp /home/fred/xulrunner/src/mozilla-2.0/xpcom/glue/nsWeakReference.cpp
/home/fred/xulrunner/src/mozilla-2.0/xpcom/glue/nsEnumeratorUtils.cpp:115:27: erreur: uninitialized const ‘EmptyEnumeratorImpl::kInstance’ [-fpermissive]
/home/fred/xulrunner/src/mozilla-2.0/xpcom/glue/nsEnumeratorUtils.cpp:50:7: note: ‘const class EmptyEnumeratorImpl’ has no user-provided default constructor
make[5]: *** [nsEnumeratorUtils.o] Erreur 1
make[5]: *** Attente des tâches non terminées....
/home/fred/xulrunner/src/mozilla-2.0/xpcom/glue/nsINIParser.cpp: In member function ‘nsresult nsINIParser::Init(nsILocalFile*)’:
/home/fred/xulrunner/src/mozilla-2.0/xpcom/glue/nsINIParser.cpp:91:14: attention : variable ‘rv’ set but not used [-Wunused-but-set-variable]
make[5] : on quitte le répertoire « /home/fred/xulrunner/src/mozilla-2.0/obj-x86_64-unknown-linux-gnu/xpcom/glue »
make[4]: *** [libs] Erreur 2
make[4] : on quitte le répertoire « /home/fred/xulrunner/src/mozilla-2.0/obj-x86_64-unknown-linux-gnu/xpcom »
make[3]: *** [libs_tier_platform] Erreur 2
make[3] : on quitte le répertoire « /home/fred/xulrunner/src/mozilla-2.0/obj-x86_64-unknown-linux-gnu »
make[2]: *** [tier_platform] Erreur 2
make[2] : on quitte le répertoire « /home/fred/xulrunner/src/mozilla-2.0/obj-x86_64-unknown-linux-gnu »
make[1]: *** [default] Erreur 2
make[1] : on quitte le répertoire « /home/fred/xulrunner/src/mozilla-2.0/obj-x86_64-unknown-linux-gnu »
make: *** [build] Erreur 2
==> ERREUR: Une erreur s'est produite dans build().
Abandon...

Additional info:
[fred@fredo-arch ~]$ pacman -Qi gcc | grep Version
Version : 4.6.0-1

Steps to reproduce:

Upgrade gcc version and try to build xulrunner.

---------------------------------------------------------------------
Comments (5)
Related Tasks (0/0)

Comment by Rémy Oudompheng (remyoudompheng) -
Sunday, 27 March 2011, 06:38 GMT-4
Probably related to "G++ no longer allows objects of
const-qualified type to be default initialized unless the type
has a user-declared default constructor." in latest GCC changes.
g++ has become more strict in its checking, add -fpermissive to
your CXXFLAGS to work around this.

Comment by Frederic Bezies (fredbezies) -
Sunday, 27 March 2011, 06:44 GMT-4
Ok. Will add it to my .mozconfig and I will tell you.

Comment by Frederic Bezies (fredbezies) -
Sunday, 27 March 2011, 07:55 GMT-4
It worked. Thanks for the tip !

I think they'll be more software which will be broken.

Comment by Allan McRae (Allan) - Thursday, 31 March 2011, 08:08 GMT-4

Assignment removed

Unassigning me. This is not a gcc bug.

Comment by Frederic Bezies (fredbezies) -
Monday, 04 April 2011, 05:11 GMT-4
Well, it is a mozilla bug. Closing ?"

Frederic Bezies claims its a mozilla bug, and he is right when pointing
at ref. {2}. Strange thing is that any c++ newcomer could have seen that
there was a severe coding error inside xpcom/glue/nsEnumeratorUtils.cpp:115
which that same average c++ newcomer could have easily fixed :
change the faulty line

const EmptyEnumeratorImpl EmptyEnumeratorImpl::kInstance

into

const EmptyEnumeratorImpl EmptyEnumeratorImpl::kInstance = EmptyEnumeratorImpl();

What next happens is very interesting and intriguing at the same time.
Bugreport ref. {2} is closed and any and all further discussion is
redirected to Bugreport ref. {3}, a very common thing todo, obviously :

"Mike Hommey [:glandium] 2011-04-30 02:35:11 PDT

*** This bug has been marked as a duplicate of bug 623126 ***"

However when reading ref. {3} some very strange new speak is uttered by
a guy by the name of Benjamin Smedberg :

"Benjamin Smedberg [:bsmedberg] 2011-01-05 05:54:24 PST

Just as with the other bug, the missing constructor is
intentional so that GCC does not emit a initialization function.
Absent a detailed explanation from a language lawyer, I don't
think I want to accept this change."

So instead of simply fixing the xulrunner c++ code, Smedberg tells his
audience, on International Workers' Day, May 1st, that he intentionally
inserted this missing constructor. Wow, how about that! All are gently
redirected 'upstream', and start playing with xulrunner-2.0 .... Now
thats a very cunning way to simply hard-ax cut-off any further
development on the xulrunner-1.9.2 branch, which is by the way exactly
the firefox-3.6.xx branch of webbrowsers .... So who is this Benjamin
Smedberg anyway, and how can he get away which such impyrialistic
behavior ??

"XUL:Benjamin Smedberg
https://wiki.mozilla.org/XUL:Benjamin_Smedberg

Home » XUL:Benjamin_Smedberg

Benjamin Smedberg is a full-time hacker who used to be a full-time
choir director and organist.

website: http://benjamin.smedbergs.us/ email: benjamin@smedbergs.us

He is currently employed by the mozdev group, a consulting company
specializing in mozilla-based technologies. As a Mozilla developer,
he focuses on architectural issues and XUL web applications.

In his former life, he was director of music at St. Patrick Church,
Washington, DC. "

"User:Benjamin Smedberg
https://developer.mozilla.org/User:Benjamin_Smedberg

Recent Activity

C++ Portability Guide
Feb 9, 2012
Remove mention of PRBool, clean up NSPR type language;
51 words added, 134 words removed

Interface documentation status
Jan 11, 2012
6 words removed

The Thread Manager
Jan 11, 2012
33 words added, 967 words removed

Making cross-thread calls using runnables
Jan 11, 2012
12 words added

Making cross-thread calls using runnables
Jan 11, 2012
This should be finished now except for a "See Also" section;
389 words added, 97 words removed

Making cross-thread calls using runnables
Jan 11, 2012
page created, 260 words added

Interfaces
Jan 11, 2012
6 words removed

nsISupports proxies
Jan 11, 2012
XPCOM proxies, removed for sanity.; 71 words added, 1231 words removed

Embedding Mozilla in a Java Application using JavaXPCOM
Jan 11, 2012
30 words added

Language Bindings
Jan 9, 2012
JavaXPCOM is mostly-dead; 11 words added, 17 words removed"

http://benjamin.smedbergs.us/blog/

Robert
PS.
{1} FS#23463 - [gcc 4.6] xulrunner cannot be built using gcc 4.6
by Frederic Bezies, Sunday, 27 March 2011, 06:26 GMT-4
https://bugs.archlinux.org/task/23463

{2} Bug 645469 - [gcc 4.6] Build process is broken while working on
embedding/browser/gtk/src/EmbedPrivate.cpp
by Frederic Bezies, 2011-03-27 02:33:26 PDT
https://bugzilla.mozilla.org/show_bug.cgi?id=645469

{3} Bug 623126 - Add constructor for nsDebugImpl, nsTraceRefcntImpl,
EmptyEnumeratorImpl, and nsSimpleUnicharStreamFactory to placate CLang
by Rafael Ávila de Espíndola, 2011-01-04 20:11:54 PST
https://bugzilla.mozilla.org/show_bug.cgi?id=623126

{4} Debian Bug report logs - #624969
icedove: FTBFS: nsEnumeratorUtils.cpp:115:27: error: uninitialized
const 'EmptyEnumeratorImpl::kInstance' [-fpermissive]
by Lucas Nussbaum, Mon, 2 May 2011 12:50:16 UTC
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624969
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org stock@stokkie.net

Mozilla announces HTML5-based phone

Posted Mar 23, 2012 13:55 UTC (Fri) by stock (guest, #5849) [Link]

I finally managed to get the browser to compile, the
end result can be found here :

http://crashrecovery.org/firefox/mdv2011/

Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org stock@stokkie.net