Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Firefox Nightly for Android users will be updated to Native UI on Tuesday (2011-11-22)

584 views
Skip to first unread message

Christian Legnitto

unread,
Nov 17, 2011, 4:59:45 PM11/17/11
to mozilla. dev. planning group
All:

On Tuesday (2011-11-22) we are planning to switch our Firefox Nightly for Android users from XUL to the Native UI[1]. This means mobile users on the Nightly channel will get an update offer on Wednesday containing the Native UI (built from the code in the birch repository[2]). We do not intend to update Honeycomb users to Native UI, as there is no tablet support yet.

There will be a final checkpoint meeting on Monday (2011-11-21) to make sure we are at the quality level our Nightly users expect. Unless the meeting says otherwise, the plan of record is to make this change for Tuesday night's automatic update.

Bugs found in the Native UI by Nightly testers should be filed in the new "Fennec Native" bugzilla component[3]. Firefox Aurora/Beta for Android users will still be running XUL and should continue to file bugs in the "Fennec" bugzilla component[4].

Going forward, daily NativeUI updates will be built out of the birch repository and offered to Firefox Nightly for Android users. At some point in the near future we intend to move the Native UI code and development completely out of birch and back to mozilla-central.

If you would like to help test Firefox for Android but do not have a device or know where to start, please check out the Firefox for Mobile Test Drivers program @ https://wiki.mozilla.org/Mobile/Testdrivers_Program

Please let me know if you have any questions.

Thanks,
Christian

[1] http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/ff8d89bfa28383bb
[2] http://hg.mozilla.org/projects/birch
[3] https://bugzilla.mozilla.org/enter_bug.cgi?product=Fennec%20Native
[4] https://bugzilla.mozilla.org/enter_bug.cgi?product=Fennec

Dao

unread,
Nov 18, 2011, 7:02:45 AM11/18/11
to
Is Sync ready or going to be ready by Tuesday? Without it, Firefox isn't
going to be useful to me on my phone...

Tim Taubert

unread,
Nov 18, 2011, 7:44:53 AM11/18/11
to dev-pl...@lists.mozilla.org
On 11/18/11 4:02 AM, Dao wrote:
> Is Sync ready or going to be ready by Tuesday? Without it, Firefox isn't
> going to be useful to me on my phone...

Sync is actively being ported to a native Android service but I guess
that won't be ready by Tuesday.

https://bugzilla.mozilla.org/show_bug.cgi?id=695463

Henri Sivonen

unread,
Nov 18, 2011, 8:32:52 AM11/18/11
to dev-pl...@lists.mozilla.org
On Thu, Nov 17, 2011 at 11:59 PM, Christian Legnitto
<cleg...@mozilla.com> wrote:
> We do not intend to update Honeycomb users to Native UI, as there is no tablet support yet.

Will tablets on the Nightly channel stop receiving updates or receive
updates built the old way?

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

Mark Finkle

unread,
Nov 18, 2011, 9:52:27 AM11/18/11
to Henri Sivonen
On 11/18/2011 08:32 AM, Henri Sivonen wrote:
> On Thu, Nov 17, 2011 at 11:59 PM, Christian Legnitto
> <cleg...@mozilla.com> wrote:
>> We do not intend to update Honeycomb users to Native UI, as there is no tablet support yet.
>
> Will tablets on the Nightly channel stop receiving updates or receive
> updates built the old way?
>

In retrospect, we may not have enough information in the AUS ping to
know if you are running a tablet version or not (I'm not trying to start
a UA-like debate:)

Therefore, tablet nightly users may be switched to Native (birch) builds
too. Tablet users can avoid this switch by moving to Aurora builds. The
XUL-based Fennec tablet nightlies are not getting new features and only
critical bug fixes.

Mark Finkle

unread,
Nov 18, 2011, 9:53:09 AM11/18/11
to Dao
On 11/18/2011 07:02 AM, Dao wrote:
> Is Sync ready or going to be ready by Tuesday? Without it, Firefox isn't
> going to be useful to me on my phone...

Sync won't be ready. I suggest moving to Aurora builds if you still need
Sync support.

Ms2ger

unread,
Nov 18, 2011, 10:02:30 AM11/18/11
to
On 11/17/2011 10:59 PM, Christian Legnitto wrote:
> make sure we are at the quality level our Nightly users expect.

On 11/18/2011 03:53 PM, Mark Finkle wrote:
> Sync won't be ready. I suggest moving to Aurora builds if you still
> need Sync support.

I don't see how these two statements add up.

Dao

unread,
Nov 18, 2011, 10:13:25 AM11/18/11
to
Aurora won't inherit the existing profile, as far as I remember, so I
think it's going to be easier for anyone in that situation to just not
update Nightly as long as it lacks Sync support...

Benjamin Smedberg

unread,
Nov 18, 2011, 10:16:36 AM11/18/11
to Mark Finkle, dev-pl...@lists.mozilla.org
Is sync support a requirement for release?

I personally don't think we should wait for sync: it is not a core
browsing feature, and we would be more competitive for *new* users by
just being fast without sync.

But I'd like to know the actual plan, whether we're going to land
nativeUI on nightly but keep it disabled on aurora until we have sync.

--BDS

Mark Finkle

unread,
Nov 18, 2011, 10:28:47 AM11/18/11
to Ms2ger
Then you should move to Aurora. We can't seriously wait for Sync to be
ready before getting nightly testers using the new application.

Mark Finkle

unread,
Nov 18, 2011, 10:35:15 AM11/18/11
to Benjamin Smedberg
I don't want to speak for the Sync team on schedules, but I can say that
Sync will not be built into the Firefox application, as it is on
desktop. On Android, the plan is to have Sync be a separate Android
Service. The service would run whenever needed, but not require Firefox
to be running. The service would ship with Firefox, but be an
independent process.

We have not discussed needing to have Sync ready for Firefox Aurora
(Native).

Robert Kaiser

unread,
Nov 18, 2011, 10:40:31 AM11/18/11
to
Mark Finkle schrieb:
> Therefore, tablet nightly users may be switched to Native (birch) builds
> too. Tablet users can avoid this switch by moving to Aurora builds. The
> XUL-based Fennec tablet nightlies are not getting new features and only
> critical bug fixes.

Now the latter is completely untrue, as Gecko gets a lot of work and
possibly new features on Nightly no matter if you guys work on anything
on the UI or not. And the UI is still way superior to anything the
native UI can provide on tablets - not to mention that the real killer
feature of Sync works fine.

I guess tablet users should just not update any more after Tuesday,
that's the sanest approach.

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! :)

Mark Finkle

unread,
Nov 18, 2011, 11:03:19 AM11/18/11
to Robert Kaiser
On 11/18/2011 10:40 AM, Robert Kaiser wrote:
> Mark Finkle schrieb:
>> Therefore, tablet nightly users may be switched to Native (birch) builds
>> too. Tablet users can avoid this switch by moving to Aurora builds. The
>> XUL-based Fennec tablet nightlies are not getting new features and only
>> critical bug fixes.
>
> Now the latter is completely untrue, as Gecko gets a lot of work and
> possibly new features on Nightly no matter if you guys work on anything
> on the UI or not. And the UI is still way superior to anything the
> native UI can provide on tablets - not to mention that the real killer
> feature of Sync works fine.
>
> I guess tablet users should just not update any more after Tuesday,
> that's the sanest approach.

... or move to Aurora, right? You'll still get critical gecko updates
that way.

Tim Taubert

unread,
Nov 18, 2011, 12:19:43 PM11/18/11
to dev-pl...@lists.mozilla.org
On 11/18/11 7:28 AM, Mark Finkle wrote:
> Then you should move to Aurora. We can't seriously wait for Sync to be
> ready before getting nightly testers using the new application.

IMHO we should use the Nightly channel to (hopefully not but maybe)
break stuff and get useful feedback in the early phase of a feature. It
seems like lots of people want it to be a lot stabler than it was
actually intended. There needs to be some kind of testing space for
early stuff.

While I don't consider a browser without Sync really useful (anymore)
I'd definitely vote for moving Birch to the Nighty channel because that
seems just like a reasonable thing to do even if it's not feature
complete, yet.

Fabrice Desré

unread,
Nov 18, 2011, 12:26:58 PM11/18/11
to
On Fri, 18 Nov 2011 16:13:25 +0100, Dao wrote:

> Aurora won't inherit the existing profile, as far as I remember, so I
> think it's going to be easier for anyone in that situation to just not
> update Nightly as long as it lacks Sync support...

Why? You can just move to aurora, and use sync in your new (aurora)
profile. You'll only need to reinstall add-ons if you had some.

Fabrice

Robert Kaiser

unread,
Nov 18, 2011, 1:20:15 PM11/18/11
to
Mark Finkle schrieb:
> ... or move to Aurora, right? You'll still get critical gecko updates
> that way.

But I want Gecko from m-c to work against. I'll probably just go and
download new XUL builds manually when I think of doing so. Is there some
way to turn off the update mechanism on the builds so I don't get those
then-pointless notifications about them? I don't see UI for it on
Android, but I guess the prefs still work?

Doug Turner

unread,
Nov 18, 2011, 1:26:52 PM11/18/11
to Robert Kaiser, dev-pl...@lists.mozilla.org

On Nov 18, 2011, at 10:20 AM, Robert Kaiser wrote:

> Mark Finkle schrieb:
>> ... or move to Aurora, right? You'll still get critical gecko updates
>> that way.
>
> But I want Gecko from m-c to work against.

If you really need m-c XUL based fennec, you can always build it yourself. What is your goal here Robert?

Doug

Christian Legnitto

unread,
Nov 18, 2011, 1:27:07 PM11/18/11
to Mark Finkle, dev-pl...@lists.mozilla.org
Apologies for the churn.

Turns out we can't limit this to just phones (so far), so we will be offering it to tablets as well.

Nightly Tablet users wanting to keep the XUL tablet UI will need to migrate to Aurora.

Thanks,
Christian
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Dietrich Ayala

unread,
Nov 18, 2011, 1:41:05 PM11/18/11
to Christian Legnitto, Mark Finkle, dev-pl...@lists.mozilla.org
Is the XUL-based Fennec for tablets going away altogether?

Is the awesome tablet UI going to be ported to native Fennec?

On Fri, Nov 18, 2011 at 10:27 AM, Christian Legnitto
<cleg...@mozilla.com> wrote:
> Apologies for the churn.
>
> Turns out we can't limit this to just phones (so far), so we will be offering it to tablets as well.
>
> Nightly Tablet users wanting to keep the XUL tablet UI will need to migrate to Aurora.
>
> Thanks,
> Christian
>
> On Nov 18, 2011, at 8:03 AM, Mark Finkle <mark....@gmail.com> wrote:
>

Doug Turner

unread,
Nov 18, 2011, 1:42:38 PM11/18/11
to Dietrich Ayala, Mark Finkle, Christian Legnitto, dev-pl...@lists.mozilla.org

On Nov 18, 2011, at 10:41 AM, Dietrich Ayala wrote:

> Is the XUL-based Fennec for tablets going away altogether?

Eventually, yes! We have a bug on file and will start on it in January.

> Is the awesome tablet UI going to be ported to native Fennec?

No awesome will be removed. :)

Jeff Griffiths

unread,
Nov 18, 2011, 1:43:16 PM11/18/11
to dev-pl...@lists.mozilla.org
On 11-11-18 10:27 AM, Christian Legnitto wrote:
> Apologies for the churn.
>
> Turns out we can't limit this to just phones (so far), so we will be
> offering it to tablets as well.
>
> Nightly Tablet users wanting to keep the XUL tablet UI will need to
> migrate to Aurora.

I'm happy to hear this; as the SDK moves to support the native UI, it
will help that all mobile builds in nightly and eventually aurora will
switch to Java. If we're going to encourage people to start hacking on
mobile add-ons, the less fragmentation the better.

Matt Brubeck

unread,
Nov 18, 2011, 1:45:16 PM11/18/11
to Christian Legnitto, Mark Finkle
On 11/18/2011 10:27 AM, Christian Legnitto wrote:
> Turns out we can't limit this to just phones (so far), so we will be offering it to tablets as well.
>
> Nightly Tablet users wanting to keep the XUL tablet UI will need to migrate to Aurora.

What is our plan for tablet users when we are ready to release the
native front-end to Beta and Release users in the Android Market? I can
think of a few possibilities:

1. Use the Android Market's multiple-APK support* to offer XUL Fennec to
Honeycomb users, and native Fennec to all other users, until the native
tablet UI is ready. I think we should do this.

* http://developer.android.com/guide/market/publishing/multiple-apks.html

2. Offer native Fennec to all Android users, including Honeycomb. I
don't think we should do this before it includes a real tablet UI,
because I think it will be a clear downgrade for Honeycomb users who
only just started using Firefox because of the new tablet UI.

3. Offer native Fennec to non-Honeycomb users, and stop offering
upgrades to Honeycomb users (i.e., continue offering XUL Fennec 10 on
Honeycomb) until the native tablet UI is ready. I don't think we can do
this because it would leave Honeycomb users without

If we choose option #1, we should consider offering nightly and aurora
update channels for XUL Fennec, and we should help Honeycomb testers
migrate to those channels. Otherwise we will be releasing software that
has not been tested on our pre-release channels. (On the other hand,
our nightly+aurora population on Android is small enough that the
benefits of testing might not justify the effort.)

Matt Brubeck

unread,
Nov 18, 2011, 2:01:33 PM11/18/11
to
On 11/18/2011 10:45 AM, Matt Brubeck wrote:
> 3. Offer native Fennec to non-Honeycomb users, and stop offering
> upgrades to Honeycomb users (i.e., continue offering XUL Fennec 10 on
> Honeycomb) until the native tablet UI is ready. I don't think we can do
> this because it would leave Honeycomb users without

"...without security updates," is what I meant to say before pressing
"Send" prematurely.

Mark Finkle

unread,
Nov 18, 2011, 2:28:39 PM11/18/11
to Matt Brubeck, Christian Legnitto
On 11/18/2011 01:45 PM, Matt Brubeck wrote:

> What is our plan for tablet users when we are ready to release the
> native front-end to Beta and Release users in the Android Market? I can
> think of a few possibilities:
>
> 1. Use the Android Market's multiple-APK support* to offer XUL Fennec to
> Honeycomb users, and native Fennec to all other users, until the native
> tablet UI is ready. I think we should do this.
>
> * http://developer.android.com/guide/market/publishing/multiple-apks.html

This is exactly the plan.

> If we choose option #1, we should consider offering nightly and aurora
> update channels for XUL Fennec, and we should help Honeycomb testers
> migrate to those channels. Otherwise we will be releasing software that
> has not been tested on our pre-release channels. (On the other hand, our
> nightly+aurora population on Android is small enough that the benefits
> of testing might not justify the effort.)

True. Beta is when we really get a decent user population.

Richard Newman

unread,
Nov 18, 2011, 2:36:36 PM11/18/11
to
On Nov 18, 4:02 am, Dao <d...@design-noir.de> wrote:
> Is Sync ready or going to be ready by Tuesday? Without it, Firefox isn't
> going to be useful to me on my phone...

No. We're aiming to have working code in December, but remember that
native Sync is all of two weeks old at this point, and there's a lot
of work to do before it'll be ready for you to try out.

Paul [sabret00the]

unread,
Nov 19, 2011, 6:29:30 AM11/19/11
to mozilla.de...@googlegroups.com, mozilla. dev. planning group
Can we not get a sync extension working and offer that to nightly testers in the short term? It seems completely illogical to try and migrate users without their data.

Paul [sabret00the]

unread,
Nov 19, 2011, 6:29:30 AM11/19/11
to mozilla. dev. planning group

Mike Hommey

unread,
Nov 19, 2011, 8:18:52 AM11/19/11
to dev-pl...@lists.mozilla.org
On Sat, Nov 19, 2011 at 03:29:30AM -0800, Paul [sabret00the] wrote:
> Can we not get a sync extension working and offer that to nightly testers in the short term? It seems completely illogical to try and migrate users without their data.

Arguably, people migrating from a xul nightly to a native-ui nightly
don't need sync to keep their data. Except if native-ui doesn't care
about "importing" data from e.g. places into its replacement. And if it
doesn't, well, you can be pretty sure users are going to be pissed off
when native-ui is released (as in, actual Firefox release).

Mike

Paul [sabret00the]

unread,
Nov 19, 2011, 11:28:21 AM11/19/11
to dev-pl...@lists.mozilla.org
Depends on the argument that you're attempting to make. If the goal is to have users install Fennec (Native) simply to look and go "ooh" then by all means. However users should be using it like a regular browser in order to maximise the chances of finding bugs and regressions. One of the features we market is Sync, thus it's something that we shouldn't deny from the alpha testers. Especially as we're looking forward to in fact adding more functionality there with the new Send To Device work that's being done. Is the Sync extension beyond porting to mobile and providing at least basic functionality in the interim?

Paul [sabret00the]

unread,
Nov 19, 2011, 11:28:21 AM11/19/11
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org

Mark Finkle

unread,
Nov 19, 2011, 3:15:52 PM11/19/11
to Mike Hommey
Upgrading from XUL to Native profiles:
https://bugzilla.mozilla.org/show_bug.cgi?id=699199

Dao

unread,
Nov 20, 2011, 5:50:48 AM11/20/11
to
On 18.11.2011 18:19, Tim Taubert wrote:
> On 11/18/11 7:28 AM, Mark Finkle wrote:
>> Then you should move to Aurora. We can't seriously wait for Sync to be
>> ready before getting nightly testers using the new application.
>
> IMHO we should use the Nightly channel to (hopefully not but maybe)
> break stuff and get useful feedback in the early phase of a feature. It
> seems like lots of people want it to be a lot stabler than it was
> actually intended.

Generally, stability is more important than ever, as mozilla-central is
supposed to spawn a release every six weeks.

This has nothing to do with stability, though. Dogfooding simply doesn't
work for me without my data.

Robert Kaiser

unread,
Nov 20, 2011, 10:03:34 AM11/20/11
to
Doug Turner schrieb:
My goal is testing as much as new core code as possible, including the
ability to report crashes, etc. while avoiding the "native UI" code as
efficiently and as long as possible (because I don't agree with it,
don't need it on a tablet at all and it lacks some quintessential
features I want and is planned to lack a lot of what I want even in the
future).

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 needs answers to. And most of the time,

Robert Kaiser

unread,
Nov 20, 2011, 10:11:05 AM11/20/11
to
Doug Turner schrieb:
>
> On Nov 18, 2011, at 10:41 AM, Dietrich Ayala wrote:
>
>> Is the XUL-based Fennec for tablets going away altogether?
>
> Eventually, yes! We have a bug on file and will start on it in January.

OK, thanks. I will not encourage anyone to use our mobile builds any
more, for the foreseeable future. I will encourage people to wait for
B2G products before touching Mozilla work on mobile devices.
(Of course I will provide any support I can within the work I'm payed
for but probably nothing going beyond that. I for myself will not use
any "native UI" builds anyhow.)

>> Is the awesome tablet UI going to be ported to native Fennec?
>
> No awesome will be removed. :)

The awesomebar algorithm will be removed. The privacy of bookmarks and
history will be removed. Open video might get undermined (not 100%
determined yet AFAIK). A lot of Add-on awesomeness will be removed (no
DOM access to existing UI, no CSS styling of existing UI). Somehow I
don't believe you fully there.

Sorry for being so blunt here, but I don't feel good for just swiping
all those concerns under the carpet - and basically everyone I talked to
in Berlin shared them equally.

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 needs answers to. And most of the time,

Justin Dolske

unread,
Nov 20, 2011, 1:51:40 PM11/20/11
to
On 11/20/11 7:11 AM, Robert Kaiser wrote:

> OK, thanks. I will not encourage anyone to use our mobile builds any
> more, for the foreseeable future.

That's a pretty crappy attitude, and seems pretty counter-productive to me.

Justin

Robert Kaiser

unread,
Nov 20, 2011, 5:51:48 PM11/20/11
to
Justin Dolske schrieb:
I understand that, and I'm not happy that I need to go there, but right
now I cannot be enthusiastic for that particular project because of
multiple reasons. And the only reasons I don't straight out hate it are
because it's 1) needed at the base (maybe not all its details though)
for phones (not for tablets IMHO) and 2) still part of Mozilla (even
though I don't even like it being called "Firefox" at the end of the
day). So I end up disliking it but supporting it as far as I need to,
but no step farther.

I hope B2G will end up being a big success because that's what I can be
really enthusiastic about.

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

Kyle Huey

unread,
Nov 20, 2011, 6:33:18 PM11/20/11
to Robert Kaiser, dev-pl...@lists.mozilla.org
On Sun, Nov 20, 2011 at 5:51 PM, Robert Kaiser <ka...@kairo.at> wrote:

> Justin Dolske schrieb:
>
> On 11/20/11 7:11 AM, Robert Kaiser wrote:
>>
>> OK, thanks. I will not encourage anyone to use our mobile builds any
>>> more, for the foreseeable future.
>>>
>>
>> That's a pretty crappy attitude, and seems pretty counter-productive to
>> me.
>>
>
> I understand that, and I'm not happy that I need to go there, but right
> now I cannot be enthusiastic for that particular project because of
> multiple reasons.


I think by this point everyone is aware of your feelings on the matter, and
continuing to rehash it isn't productive for anyone.

Can we please move this thread back on topic?

- Kyle

Paul [sabret00the]

unread,
Nov 21, 2011, 5:15:56 AM11/21/11
to
On Sunday, 20 November 2011 15:11:05 UTC, Robert Kaiser wrote:
> The awesomebar algorithm will be removed. The privacy of bookmarks and
> history will be removed. Open video might get undermined (not 100%
> determined yet AFAIK). A lot of Add-on awesomeness will be removed (no
> DOM access to existing UI, no CSS styling of existing UI). Somehow I
> don't believe you fully there.

Can I have confirmation of this please? Are the above points, particularly the awesomebar algorithm and the privacy concerns.

Michael Lefevre

unread,
Nov 21, 2011, 5:56:52 AM11/21/11
to
That seems to be a matter of debate. The switch from XUL, the user-agent
change and the switch to native database (with lack of sync/awesomebar)
all sound like pretty radical changes for a version 7/8 product. Is
there some kind of roadmap or techie-user-targeted messaging for
existing users about all this?

Getting users to upgrade to a newer release which is missing features of
an older release based on the promise that things will be improved in
future versions doesn't sound easy (although I know Firefox has a
relatively small number of users on mobile currently...)

Michael

JP Rosevear

unread,
Nov 21, 2011, 10:23:43 AM11/21/11
to Christian Legnitto, mozilla. dev. planning group
On Thu, 2011-11-17 at 13:59 -0800, Christian Legnitto wrote:
> All:
>
> On Tuesday (2011-11-22) we are planning to switch our Firefox Nightly for Android users from XUL to the Native UI[1]. This means mobile users on the Nightly channel will get an update offer on Wednesday containing the Native UI (built from the code in the birch repository[2]). We do not intend to update Honeycomb users to Native UI, as there is no tablet support yet.
>
> There will be a final checkpoint meeting on Monday (2011-11-21) to
> make sure we are at the quality level our Nightly users expect. Unless
> the meeting says otherwise, the plan of record is to make this change
> for Tuesday night's automatic update.

Is this meeting scheduled yet?

Thanks,

-JP
--
JP Rosevear <j...@mozilla.com>
Mozilla

Doug Turner

unread,
Nov 21, 2011, 10:31:43 AM11/21/11
to Michael Lefevre, dev-pl...@lists.mozilla.org

On Nov 21, 2011, at 2:56 AM, Michael Lefevre wrote:

> On 18/11/2011 18:42, Doug Turner wrote:
>>
>> On Nov 18, 2011, at 10:41 AM, Dietrich Ayala wrote:
>>
>>> Is the XUL-based Fennec for tablets going away altogether?
>>
>> Eventually, yes! We have a bug on file and will start on it in January.
>>
>>> Is the awesome tablet UI going to be ported to native Fennec?
>>
>> No awesome will be removed. :)
>
> That seems to be a matter of debate. The switch from XUL, the user-agent change and the switch to native database (with lack of sync/awesomebar) all sound like pretty radical changes for a version 7/8 product. Is there some kind of roadmap or techie-user-targeted messaging for existing users about all this?

This really is a rewrite. We are doing our best to have similar features to the 7/8 product and having an aggressive timeline. There have been a few blog posts about this work. For example:

http://lucasr.org/2011/11/15/native-ui-for-firefox-on-android/


> Getting users to upgrade to a newer release which is missing features of an older release based on the promise that things will be improved in future versions doesn't sound easy (although I know Firefox has a relatively small number of users on mobile currently…)

Yup. The idea is that it is going to be a lot faster and a lot smaller. Those two features have been much of the drive behind this effort. For more information, you can check out:

https://wiki.mozilla.org/Fennec/NativeUI

Regards,
Doug

Christian Legnitto

unread,
Nov 21, 2011, 1:32:37 PM11/21/11
to JP Rosevear, mozilla. dev. planning group
I believe at the mobile triage meeting it was decided to just do it via email. I'll check with the team and make sure the thread / discussion is somewhere public.

Thanks,
Christian

Gervase Markham

unread,
Nov 22, 2011, 5:49:23 AM11/22/11
to Christian Legnitto, JP Rosevear
On 21/11/11 18:32, Christian Legnitto wrote:
> I believe at the mobile triage meeting it was decided to just do it
> via email. I'll check with the team and make sure the thread /
> discussion is somewhere public.

Publishing a discussion which is already finished is somewhat different
to allowing people to give input while the discussion is still under way
:-) Switching a major decision like this at the last minute from a
public meeting to private email does not sound terribly awesome :-(

Has the decision been made? If so, what was it? If not, how do people
provide input?

Gerv

beltzner

unread,
Nov 22, 2011, 10:22:20 AM11/22/11
to Gervase Markham, dev-pl...@lists.mozilla.org, JP Rosevear
On Tue, Nov 22, 2011 at 5:49 AM, Gervase Markham <ge...@mozilla.org> wrote:
> Publishing a discussion which is already finished is somewhat different to
> allowing people to give input while the discussion is still under way :-)

I'm not sure that's a requirement for every decision we make, fwiw,
and not sure that it should be. Not everything requires public review
or should block on waiting for input, especially when it involves a
subset of the general consumer audience / only affects nightly
testers, etc.

> Switching a major decision like this at the last minute from a public
> meeting to private email does not sound terribly awesome :-(

The major decision in question, let's recall, is the same sort of
major decision made at all triage checkpoint meetings - one about the
relative quality and whether or not we are happy to push out a
release. I don't think you're actually proposing that all such
meetings gate on some form of wide public approval, since that's not
what we do for other triage meetings (though triage calls are usually
open to the public, despite being irregularly scheduled!)

> Has the decision been made? If so, what was it? If not, how do people
> provide input?

I suspect you're actually talking about the decision to migrate
nightly users to Native UI at some point in the future, and yes, that
decision seems to have been made. Arguments against and in support are
in this thread, and as I see it, have been reasonably addressed.

cheers,
mike

Gervase Markham

unread,
Nov 22, 2011, 10:57:40 AM11/22/11
to beltzner, JP Rosevear
On 22/11/11 15:22, beltzner wrote:
> On Tue, Nov 22, 2011 at 5:49 AM, Gervase Markham<ge...@mozilla.org> wrote:
>> Publishing a discussion which is already finished is somewhat different to
>> allowing people to give input while the discussion is still under way :-)
>
> I'm not sure that's a requirement for every decision we make, fwiw,

...and I didn't argue that it should be.

>> Switching a major decision like this at the last minute from a public
>> meeting to private email does not sound terribly awesome :-(
>
> The major decision in question, let's recall, is the same sort of
> major decision made at all triage checkpoint meetings - one about the
> relative quality and whether or not we are happy to push out a
> release. I don't think you're actually proposing that all such
> meetings gate on some form of wide public approval, since that's not
> what we do for other triage meetings (though triage calls are usually
> open to the public, despite being irregularly scheduled!)

I am not requiring "wide public approval". (That seems to be the second
straw man in your comment, which is quite unlike you.)

My objection is simply this: this is a pretty major decision, a meeting
was announced where it would be made, there was interest in this group
from people who seemed to want to be involved, and then we were told
that there's no meeting - an unknown small group of people decided it by
private email.

This does not sound to me like the workings of a community-based
organization.

(I admit my impetus to object to this is strengthened by the fact that
I've been trying to use native nightlies on a tablet to surf the web for
half an hour every day for the last week; for 5 days of those it crashed
immediately on startup, and for the last two the scrolling and zooming
behaviour, and rendering glitches, have made it basically unusable.)

Gerv

Doug Turner

unread,
Nov 22, 2011, 11:19:09 AM11/22/11
to Gervase Markham, dev-pl...@lists.mozilla.org, JP Rosevear

On Nov 22, 2011, at 7:57 AM, Gervase Markham wrote:

> (I admit my impetus to object to this is strengthened by the fact that I've been trying to use native nightlies on a tablet to surf the web for half an hour every day for the last week; for 5 days of those it crashed immediately on startup, and for the last two the scrolling and zooming behaviour, and rendering glitches, have made it basically unusable.)

What are the bug numbers? Do you have crash stat urls? (about:crashes).


Aleksandr Milewski

unread,
Nov 22, 2011, 11:22:46 AM11/22/11
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org
This has not been answered in this thread, and I'm not clear where to find the answer. Some documentation on the privacy implications of this branch would be greatly appreciated.

"No Surprises" is a core tenet of our privacy stance, and auto-updating to something far less private is surprising to me. Nightly should not be exempt.

And I'm not saying "don't do it", I'm saying "message clearly".

-Zandr

Gervase Markham

unread,
Nov 22, 2011, 11:28:48 AM11/22/11
to Doug Turner, JP Rosevear
On 22/11/11 16:19, Doug Turner wrote:
> What are the bug numbers? Do you have crash stat urls? (about:crashes).

I filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=702677
which you marked as a dupe of:
https://bugzilla.mozilla.org/show_bug.cgi?id=702365
which was worked around 2 nights ago (although I still see frequent
crashes, presumably for other reasons).

I have logged some crashes, but I think you know the cause of the
problem we are talking about, so I'm not sure if URLs are useful.
Clicking on the links on about:crashes doesn't work, so I don't know
what the URLs are anyway, but here's one ID of the 4 I have listed:

2cd9d4ed-1a8a-3b72-74238efa-56843dde

Gerv

Brad Lassey

unread,
Nov 22, 2011, 12:33:41 PM11/22/11
to beltzner, JP Rosevear
On Tuesday, November 22, 2011 10:57:40 AM UTC-5, Gervase Markham wrote:
> On 22/11/11 15:22, beltzner wrote:
> > I'm not sure that's a requirement for every decision we make, fwiw,
>
> ...and I didn't argue that it should be.
It sounds like you're arguing that this one should be, establishing that that is not required is useful
>
> >> Switching a major decision like this at the last minute from a public
> >> meeting to private email does not sound terribly awesome :-(
> >
> > The major decision in question, let's recall, is the same sort of
> > major decision made at all triage checkpoint meetings - one about the
> > relative quality and whether or not we are happy to push out a
> > release. I don't think you're actually proposing that all such
> > meetings gate on some form of wide public approval, since that's not
> > what we do for other triage meetings (though triage calls are usually
> > open to the public, despite being irregularly scheduled!)
>
> I am not requiring "wide public approval". (That seems to be the second
> straw man in your comment, which is quite unlike you.)
Again, this is pretty close to how I read what you wrote. Rather than defending your position, you've chosen to simply undermine Mike's argument on stlye points.

> My objection is simply this: this is a pretty major decision, a meeting
> was announced where it would be made, there was interest in this group
> from people who seemed to want to be involved, and then we were told
> that there's no meeting - an unknown small group of people decided it by
> private email.
Really? This is a major decision? This code will be merged into mozilla-central eventually. If you're testing mozilla-central nightlies at this point you're not testing what we're going to release and you're going to be running the native UI at some point. The discussion is when that should happen. We typically allow the drivers of a product to make those sorts of decisions. The drivers of the Fennec product are pretty well identified, so it is by no means an "unknown" group.

Gervase Markham

unread,
Nov 22, 2011, 12:55:16 PM11/22/11
to mozilla.de...@googlegroups.com, Brad Lassey, beltzner, JP Rosevear
On 22/11/11 17:33, Brad Lassey wrote:
> Again, this is pretty close to how I read what you wrote. Rather than
> defending your position, you've chosen to simply undermine Mike's
> argument on stlye points.

I am saying that _this_ decision is important; perhaps people are
incorrectly generalizing this to "all decisions" because my message did
not make it sufficiently clear why I think this decision is different to
your average run-of-the-mill decision. If so, sorry. Let me try and do
that (below).

> Really? This is a major decision? This code will be merged into
> mozilla-central eventually.

I am not saying "never send birch to nightly".

> If you're testing mozilla-central
> nightlies at this point you're not testing what we're going to
> release and you're going to be running the native UI at some point.
> The discussion is when that should happen. We typically allow the
> drivers of a product to make those sorts of decisions. The drivers of
> the Fennec product are pretty well identified, so it is by no means
> an "unknown" group.

The decision is major because it involves replacing what users are using
- not with an incremental improvement on what they had previously, but
with something which 'removes' a number of features (as in, they aren't
reimplemented), is more crashy and a lot harder to use, and preserves
their privacy less. This is not the sort of action we take at Mozilla on
a regular basis!

That being true, it seems weird that this decision is made in _less_ of
a public, open and transparent fashion than the run-of-the-mill ones.

I don't want to bikeshed on process, but frankly I'm surprised at the
level of resistance to what seems to me like a reasonable observation
that, as an open project, it would be good if we didn't suddenly decide
to make decisions which were previously made in public, in private.

Gerv

beltzner

unread,
Nov 22, 2011, 1:11:23 PM11/22/11
to mozilla.dev.planning group, Gervase Markham, JP Rosevear, Brad Lassey
On Tue, Nov 22, 2011 at 1:09 PM, beltzner <mbel...@gmail.com> wrote:
On Tue, Nov 22, 2011 at 12:55 PM, Gervase Markham <ge...@mozilla.org> wrote:
> I don't want to bikeshed on process, but frankly I'm surprised at the level
> of resistance to what seems to me like a reasonable observation that, as an
> open project, it would be good if we didn't suddenly decide to make
> decisions which were previously made in public, in private.

I don't think you're bikesheding on process; I think you're conflating
the specific decision in question - which is if the release is at a
level of quality and functionality that's commensurate with what we
term Nightly - with the broader decision to move to Native UI which
has similarly broader implications on privacy (some of which are, a
far as I can tell, heresay and not based in any points of fact!) and
available functionality.

The former, which I must stress is the decision that we're discussing,
is really quite status quo.

The latter, which I remind you has been discussed and brought up
elsewhere and publicly in this and various Mobile fora, has already
been set down. I do understand how you feeel, though, as you
apparently missed that conversation. Things are moving rapidly, and as
someone who used to be intimately involved in all ongoings who is now
trying to keep up as a community observer, stuff gets missed. At the
end of the day, though, I've found that all reasonable questions have
been answered in due course, and concerns have been heard if not
necessarily addressed in the specific way desired by every
contributor/community member. So goes module ownership, though!

cheers,
mike

Robert Kaiser

unread,
Nov 23, 2011, 1:49:55 PM11/23/11
to
Robert Kaiser schrieb:
> Sorry for being so blunt here

I regret the tone I did get into on this topic and the way I ended up
phrasing those messages after frustration cooked up inside me (caused by
multiple factors, including completely unrelated personal things, the
hardness of realizing that Mozilla has grown large enough that I can't
be in the loop on everything any more, and also a feeling that decisions
in this area haven't been communicated to the community well enough -
maybe because some of them aren't even set in stone yet, as I realized
meanwhile).

I should have asked politely about how we are planning to deal with
privacy concerns about using the system storage, about if we really must
apply all this to tablets the same as phone, and about which compelling
arguments we will have for users (or if we are working on a good story
there) to switch from the stock browser (potentially Chrome next year)
to our offering (as I'll need those before I'll be able to persuade
people to actually make that switch) - but I ended up falling back to
years of "flame war training" I had and messed it up with aggressive
stances. I'm very sorry. (At least I still have this signature text
under it that I adopted the last time this happened to me, I guess I
still have some things to learn in that area.)

I know people are working very hard and the climate in this project is a
bit on the edge anyhow as we are betting a whole lot on this working out
- both as an organization and a community. The last thing it needs is
someone like me shooting darts, so I'll try and be more encouraging and
positive and turning allegation into inquiry and stop energy into
constructivism as much as I can.

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
0 new messages