[Cross-posted to dev.planning, followups to dev.platforms.mobile please]
Hey folks,
After substantial discussion, we have decided to build future versions of Firefox on Android with a native UI instead of the current XUL implementation. The team is already working on this project on the birch branch [1], and we are tracking the early work on the wiki. [2] To be clear, we're still building on Gecko. This change is just about the way we build our UI.
There are several reasons for making this change, most notably:
* Startup - A native UI can be presented much faster than a XUL based UI, since it can happen in parallel with Gecko startup. This means startup times in fractions of a second, versus several seconds for a XUL UI on some phones.
* Memory use - We believe a native UI will use significantly less memory
* Responsiveness - A native UI has the potential for beautiful panning and zooming performance
Firefox on Android is a critical part of supporting the open web, and this decision puts us in a position to build the best Firefox possible.
It's still early days, so we have a lot of questions to answer. We’re talking with the Add-on SDK team about the best way to support extensions. We’re talking with l10n about how to ensure we support Firefox users wherever they live around the world.
Next week, the team is meeting in Toronto to break down this work and prioritize it. We'll be on IRC in #mobile if you want to get involved, and pushing updates to the repo regularly. By the end of next week, we will have a clearer outline of the work ahead, and we'll update this list with those details.
It's too early for us to determine when this work will be ready for users, but we are certain that it will not impact the versions currently on the Beta and Aurora channels. Firefox 8 and 9 will ship with the XUL UI, including the new UI for tablets, while we build the native UI.
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation.
At the All Hands, it was suggested that we only needed to do the main UI
natively, as that's the bit which has to come up fast. We could carry on
having all the secondary UI (e.g. addons screen, options etc.) in XUL,
which would lessen the work of porting add-ons and keep people in
familiar territory for as long as possible.
As I read it, all of the native UI benefits you list would be realised
by doing this.
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation.
Does that stand true for phones only or for tablets as well?
I seriously doubt that doing non-Gecko-rendered UI is aligned with doing things the Mozilla way at all, but I understand that the thinking seems to be that Android phones don't deserve to have all the power we can deliver, and I'm seriously hoping B2G will be a crushing success as then this native UI thing will worry me less. That said, I hope at least tablets, which already have a quite good experience with the current UI, will stay with full Mozilla power.
Robert Kaiser
-- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
Robert Kaiser wrote:
> I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
> things the Mozilla way at all
When the Communicator 5 source code was released, and the Mozilla project started, we had three native front ends and three distinct front end teams. Resources were likely too limited to maintain those front ends and there was the possibility that everything but Windows would be dropped.
XUL and XPFE was able to moot that possibility and let us build a great browser across many platforms, but it was not because XUL was the "Mozilla way" it was because the Mozilla way was flexibility and ingenuity in the face of existential challenges.
> Robert Kaiser wrote:
>> I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
>> things the Mozilla way at all
> When the Communicator 5 source code was released, and the Mozilla
> project started, we had three native front ends and three distinct front
> end teams.
And I'm pretty sure Firefox would not have been a smashing success using those, because they didn't support the kind of flexible and powerful add-on technology that we can only support because our UI is "webby".
> XUL and XPFE was able to moot that possibility and let us build a great
> browser across many platforms, but it was not because XUL was the
> "Mozilla way" it was because the Mozilla way was flexibility and
> ingenuity in the face of existential challenges.
There was no Mozilla the way we define it now back then. What is the "Mozilla way" now only evolved over time - and without having Gecko render the UI, the project would have died with Netscape, as it wouldn't have been any more interesting or innovative technology than IE - and I strongly believe that a Firefox with native Android UI won't be very much better than the native Android browser.
Thankfully, there's still B2G, which takes a completely different route and one I really feel at home with. ;-)
Robert Kaiser
-- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
Robert Kaiser wrote:
> Asa Dotzler schrieb:
>> Robert Kaiser wrote:
>>> I seriously doubt that doing non-Gecko-rendered UI is aligned with doing
>>> things the Mozilla way at all
>> When the Communicator 5 source code was released, and the Mozilla
>> project started, we had three native front ends and three distinct front
>> end teams.
> And I'm pretty sure Firefox would not have been a smashing success using
> those, because they didn't support the kind of flexible and powerful
> add-on technology that we can only support because our UI is "webby".
>> XUL and XPFE was able to moot that possibility and let us build a great
>> browser across many platforms, but it was not because XUL was the
>> "Mozilla way" it was because the Mozilla way was flexibility and
>> ingenuity in the face of existential challenges.
> There was no Mozilla the way we define it now back then. What is the
> "Mozilla way" now only evolved over time - and without having Gecko
> render the UI, the project would have died with Netscape, as it wouldn't
> have been any more interesting or innovative technology than IE - and I
> strongly believe that a Firefox with native Android UI won't be very
> much better than the native Android browser.
> Thankfully, there's still B2G, which takes a completely different route
> and one I really feel at home with. ;-)
Where's that Kairo enthusiasm I know and love?! :D We make great products. We're not bound by any technology. We bend the technology to our will to make users happy. If we need to, we'll make add-ons work with a native UI. There are not technology barriers there we can't overcome. Cowboy up, Kairo! We got big hills to climb :D
On Sat, 15 Oct 2011 16:40:17 +0600, Gervase Markham wrote:
> At the All Hands, it was suggested that we only needed to do the main UI
> natively, as that's the bit which has to come up fast. We could carry on
> having all the secondary UI (e.g. addons screen, options etc.) in XUL,
> which would lessen the work of porting add-ons and keep people in
> familiar territory for as long as possible.
It's very likely that we'll have some in-content UI like a mobile friendly version of about:addons. For preferences, downloads, etc. we'll need some input from the UX guys.
> As I read it, all of the native UI benefits you list would be realised
> by doing this.
> What is the current plan in that regard?
I started a wiki page about add-on support in the new UI at https://
wiki.mozilla.org/Fennec/NativeUI/addons . Inputs welcome!
Honestly I'm scared by your plan: you've already decided to build a native UI but, as far as I understand, you have no idea of the problems you'll have on the l10n side. If you realize that localization will be greatly limited by a native UI, will you change your decision?
> [Cross-posted to dev.planning, followups to dev.platforms.mobile please]
> Hey folks,
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation. The team is already working on this project on the birch
> branch [1], and we are tracking the early work on the wiki. [2] To be
> clear, we're still building on Gecko. This change is just about the way
> we build our UI.
> There are several reasons for making this change, most notably:
> * Startup - A native UI can be presented much faster than a XUL based
> UI, since it can happen in parallel with Gecko startup. This means
> startup times in fractions of a second, versus several seconds for a XUL
> UI on some phones.
> * Memory use - We believe a native UI will use significantly less memory
> * Responsiveness - A native UI has the potential for beautiful panning
> and zooming performance
> Firefox on Android is a critical part of supporting the open web, and
> this decision puts us in a position to build the best Firefox possible.
> It's still early days, so we have a lot of questions to answer. We’re
> talking with the Add-on SDK team about the best way to support
> extensions. We’re talking with l10n about how to ensure we support
> Firefox users wherever they live around the world.
> Next week, the team is meeting in Toronto to break down this work and
> prioritize it. We'll be on IRC in #mobile if you want to get involved,
> and pushing updates to the repo regularly. By the end of next week, we
> will have a clearer outline of the work ahead, and we'll update this
> list with those details.
> It's too early for us to determine when this work will be ready for
> users, but we are certain that it will not impact the versions currently
> on the Beta and Aurora channels. Firefox 8 and 9 will ship with the XUL
> UI, including the new UI for tablets, while we build the native UI.
> Where's that Kairo enthusiasm I know and love?! :D
It's there, and I'm fully enthusiastic for B2G when it comes to mobile. I'm not for a native Android UI, though. I don't have to be for every single thing we're doing. I sincerely hope that the tablet UI we have now, which rocks (at least when using Personas), will stay alive and will not be replaced with some (gah) Java-like gunk.
Robert Kaiser
-- Note that any statements of mine - no matter how passionate - are never meant to be offensive but very often as food for thought or possible arguments that we as a community should think about. And most of the time, I even appreciate irony and fun! :)
> Honestly I'm scared by your plan: you've already decided to build a native UI but, as far as I understand, you have no idea of the problems you'll have on the l10n side. If you realize that localization will be greatly limited by a native UI, will you change your decision?
> Honestly I'm scared by your plan: you've already decided to build a
> native UI but, as far as I understand, you have no idea of the problems
> you'll have on the l10n side. If you realize that localization will be
> greatly limited by a native UI, will you change your decision?
as you can't see the current concerns page, here's what's currently on it:
available locale codes?
how to ship localizations?
l20n mobile first?
locale selection in java/in gecko
testing for contributors
devices
emulators? (Pike never got one to run on mac)
If you have more, add them here or in email, please.
And yes, I don't think that the native android stuff is a step forward l10n-infra-wise. I'll need to get a hello-world to come up to see what native android is really doing UI wise, and see what options we have to work in a good way at the side.
Hi Doug,
I can't access the wiki with my LDAP account and unfortunately I'll be at
work on Friday (4PM). Possible concerns:
- Don't break existing tools and formats (see bug 622429 above, and
understand if this is still a issue).
- Do we have the same kind of flexibility we currently have with XUL? For
example widths that can be set for each locale in .dtd files.
- How do you plan to test this? I'm worried, in particular considering
the new release cycle.
Accessing this list via e-mail wasn't a smart idea, I received only
Doug's answer :-\ Trying now with Google Groups.
The list you wrote (is it in the wiki page Doug mentioned?) seems
already quite comprehensive, please publish Meeting Notes somewhere
(planet would be great) ;-)
On Oct 14, 5:28 pm, Johnathan Nightingale <john...@mozilla.com> wrote:
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation.
How will this work out for mobile Firefox on other platforms? For
example Meego, upcoming Tizen and new emerging free distributions
based on the Mer core (like Mer + Plasma Active)? They are normative
Linux, not Android. Does it mean you plan now to write a native UI for
every single case? Or Mozilla is dropping a powerful cross platform
appeal and putting Android as the only worthy candidate?
> Hi Doug,
> I can't access the wiki with my LDAP account and unfortunately I'll be at
> work on Friday (4PM). Possible concerns:
> - Don't break existing tools and formats (see bug 622429 above, and
> understand if this is still a issue).
> - Do we have the same kind of flexibility we currently have with XUL? For
> example widths that can be set for each locale in .dtd files.
> - How do you plan to test this? I'm worried, in particular considering
> the new release cycle.
I was told that the setup would have a thread running Java UI and a thread running Gecko (web content).
So we'd give up all the good things multiple content process could give
us in the future (I know, Fennec has just one content process atm).
If one tab/domain does some animation, and some other tab does some heave js too, the animation won't be smooth.
Also, if gecko crashes, the whole browser crashes.
There seems to be some perf problems integrating Flash to mobile-E10s.
But is that because of puppet widgets? Could content process Gecko paint straight to the OS level?
I'm worried that if there will never be more than one process,
which has just one thread for Gecko's DOM operations, we can't utilize
multicore cpus well enough in the near future.
-Olli
On 10/15/2011 12:28 AM, Johnathan Nightingale wrote:
> [Cross-posted to dev.planning, followups to dev.platforms.mobile please]
> Hey folks,
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation. The team is already working on this project on the birch
> branch [1], and we are tracking the early work on the wiki. [2] To be
> clear, we're still building on Gecko. This change is just about the way
> we build our UI.
> There are several reasons for making this change, most notably:
> * Startup - A native UI can be presented much faster than a XUL based
> UI, since it can happen in parallel with Gecko startup. This means
> startup times in fractions of a second, versus several seconds for a XUL
> UI on some phones.
> * Memory use - We believe a native UI will use significantly less memory
> * Responsiveness - A native UI has the potential for beautiful panning
> and zooming performance
> Firefox on Android is a critical part of supporting the open web, and
> this decision puts us in a position to build the best Firefox possible.
> It's still early days, so we have a lot of questions to answer. We’re
> talking with the Add-on SDK team about the best way to support
> extensions. We’re talking with l10n about how to ensure we support
> Firefox users wherever they live around the world.
> Next week, the team is meeting in Toronto to break down this work and
> prioritize it. We'll be on IRC in #mobile if you want to get involved,
> and pushing updates to the repo regularly. By the end of next week, we
> will have a clearer outline of the work ahead, and we'll update this
> list with those details.
> It's too early for us to determine when this work will be ready for
> users, but we are certain that it will not impact the versions currently
> on the Beta and Aurora channels. Firefox 8 and 9 will ship with the XUL
> UI, including the new UI for tablets, while we build the native UI.
> On Oct 14, 5:28 pm, Johnathan Nightingale <john...@mozilla.com> wrote:
> > After substantial discussion, we have decided to build future versions
> > of Firefox on Android with a native UI instead of the current XUL
> > implementation.
> How will this work out for mobile Firefox on other platforms? For
> example Meego, upcoming Tizen and new emerging free distributions
> based on the Mer core (like Mer + Plasma Active)? They are normative
> Linux, not Android. Does it mean you plan now to write a native UI for
> every single case? Or Mozilla is dropping a powerful cross platform
> appeal and putting Android as the only worthy candidate?
> Regards,
> Hillel.
This move also concerns many others...
T'would be great if this post could be addressed by Mozilla reps
charged w/this new direction?
The e10s issue involving flash has to do with the fact that the android extensions to the NPAPI gives the plugin direct access to the jvm, which only exists in the chrome process. We actually implemented a cross process jni interface, only to find out that there are certain things that Flash expects to run on the main java thread, which is impossible to do from the content process.
> After substantial discussion, we have decided to build future versions
> of Firefox on Android with a native UI instead of the current XUL
> implementation. The team is already working on this project on the birch
> branch [1], and we are tracking the early work on the wiki. [2] To be
> clear, we're still building on Gecko. This change is just about the way
> we build our UI.
This thread led to a lot of community questions, but not very many
answers. Is there any possibility of the team engaging with some of them?
In particular, I would like to ask:
- Is the XUL UI going to be abandoned, or are we developing the two in
parallel? Arguments against abandoning it include all the same
cross-platform ones against abandoning XUL on the desktop, plus also
that presumably we need a XUL-based browser UI for B2G.
- Do we plan to do this just for phones, or also for tablets (which have
more horsepower, more memory and perhaps a touch less need for immediacy)?
- Do we plan to reimplement all UI natively, or just the
performance-critical main window?
> This thread led to a lot of community questions, but not very many
> answers. Is there any possibility of the team engaging with some of them?
Here is some current information, subject to change of course.
> In particular, I would like to ask:
> - Is the XUL UI going to be abandoned, or are we developing the two in
> parallel? Arguments against abandoning it include all the same
> cross-platform ones against abandoning XUL on the desktop, plus also
> that presumably we need a XUL-based browser UI for B2G.
# The XUL UI will live on in the Mozilla source repo. The XUL UI is used for Maemo/Meego and is still actively being maintained by Mozilla[1] and contributors. We plan to add the Native UI code to mozilla-central in a way that does not obsolete the XUL UI code.
> - Do we plan to do this just for phones, or also for tablets (which have
> more horsepower, more memory and perhaps a touch less need for immediacy)?
# The XUL UI will be used in the Fx8, Fx9 and Fx10 releases on phones and tablets. The XUL UI will likely be used on Fx11 and perhaps Fx12 releases on tablets - until the Native UI implements full tablet support as well. Release roadmaps are hard to predict and can change, but this gives you a general idea.
> - Do we plan to reimplement all UI natively, or just the
> performance-critical main window?
# We plan on implementing all chrome UI using native widgets.
# We plan on supporting add-ons using the Native UI as well. XUL UI overlays won't be possible, but restartless add-ons will be supported. A NativeWindow API, which allows add-ons to interop with parts of the native chrome UI, has started forming in the nightly builds.
----
[1] - since Mozilla is shipping the XUL UI for some "in the pipeline" releases.
Things are going to be in-flux and interesting, in particular for l10n.
Right now, folks are working on the birch project repo, and use embedding/android/locales/en-US/android_strings.dtd for their UI strings.
That's at least the back-up plan, I'm currently diving into what android really does to check our options. I'm scribbling down my findings on https://wiki.mozilla.org/L10n:Native_Android.
Which repos, when, etc are all in TBD, we're meeting on a weekly basis for now.
On Oct 27, 11:44 am, Mark Finkle <mark.fin...@gmail.com> wrote:
> The XUL UI will live on in the Mozilla source repo. The XUL UI is used
> for Maemo/Meego and is still actively being maintained by Mozilla[1] and
> contributors. We plan to add the Native UI code to mozilla-central in a
> way that does not obsolete the XUL UI code.
Do you consider at some point supporting a full blown Qt port, which
could optimize Maemo/Meego and future Tizen/Nemo Firefox ports? It
falls in line with your move towards native UI for optimization
purposes. Qt port can also benefit desktop KDE users.
