The purpose of binary components

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Philipp Kewisch-2
Hi Folks,

In the case of Lightning we are actually working on getting rid of
binary components already, but only due to the fact that the fast
release pace is making users unhappy since we have a new version every
release and older releases are incompatible and also the problems that
multiple release packages bring. This rewrite taking a substantial
amount of time, since I am in the process of rewriting libical from C to
Javascript.

I've attempted to go the js-ctypes route, but as Simon (Paquet) said I
hit the problem with sticking ctypes refs on js objects and not being
able to destruct them. The workarounds that were posted sound like a
great hack to me and that's not a route I would like to go. I really
would need to call a custom libical function to free the memory
correctly, since I believe they keep hold of their components too.

Another thing that is really bugging me about this is the impact on
addon developers you would impose by this change. With Lightning we have
had many situations in the past where the Mozilla Platform was changed
and Lightning was forced to do time-consuming changes to adapt. Just to
name a few: component manifest changes, ability to create new threads in
js (before ChromeWorkers were introduced), removing Components access in
ChromeWorkers, the new release process.

Most of those changes required us to do something totally different and
restructure the code. This is a big problem, not only for us but also
for other addon developers.

Now again a large change is being planned that will impact us and
cripple the heart of Lightning. We are only lucky this time that we have
started converting before the discussion came up. I really would like to
spend more time improving the product instead of running behind platform
changes.

The situation Simon (Kornblith) mentioned sounds so very familiar: you
are planning on changing things, but this will break things bad for the
one or other, resulting in either lots of work or ugly code, or both.

I also fear that stopping it on AMO is only a start. As others have
said, its only a small part of binary addons that are on AMO. You won't
be fixing the problem by banning them from AMO, so at some point I could
imagine you'd just no longer load binary components from extensions as a
whole. Maybe I'm looking too far into the future here, I just don't
think stopping them at AMO is the right thing to do.

Although for once Lightning might not take the greatest hit (unless you
do this before Firefox 13), I really think you should desist.

Thanks for considering
Philipp
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Alex Vincent
In reply to this post by Philip Chee
On 1/17/2012 8:24 PM, Philip Chee wrote:
> Well here's the problem. Enigmail tried multiple times to get their IPC
> code into core but was rejected each time. Eventually they were
> grudgingly allowed to put their code into a separate repository
> somewhere in hg.mozilla.org where nobody can find it.
>
> Phil
>

http://hg.mozilla.org/ipccode/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Zack Weinberg-2
In reply to this post by Zack Weinberg-2
On 2012-01-18 12:08 AM, Mike Hommey wrote:

> On Tue, Jan 17, 2012 at 01:24:59PM -0800, Zack Weinberg wrote:
>
>> To inform the choice between D and E, could authors of applications
>> outside m-c please chime in and tell us what they still need binary
>> components for?  It seems *highly* desirable to me to get to a point
>> where Thunderbird, Seamonkey, etc don't need any binary components
>> beyond what's already in libxul.
>
> Do you suggest that things like the ldap client implementation would
> need to be in m-c's libxul?

I suppose I do.  It seems to me that B2G would ultimately want that anyway.

A lot of the pushback from non-Firefox application authors seems to boil
down to "we have a lot of old crufty C++ and there isn't the manpower to
get it up to the current quality standard required for m-c" and/or
"there isn't enough interest from the Firefox side of things in
including code in m-c that Firefox doesn't require itself".  Again, B2G
implies (to me) that both of those are going to have to change going
forward.  A smartphone that can't access corporate email accounts is not
going to be appealing to a large segment of the market for smartphones.

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Blake Winton
On 19-01-12 17:31 , Zack Weinberg wrote:

> On 2012-01-18 12:08 AM, Mike Hommey wrote:
>> On Tue, Jan 17, 2012 at 01:24:59PM -0800, Zack Weinberg wrote:
>>> It seems *highly* desirable to me to get to a point
>>> where Thunderbird, Seamonkey, etc don't need any binary components
>>> beyond what's already in libxul.
>> Do you suggest that things like the ldap client implementation would
>> need to be in m-c's libxul?
>
> I suppose I do. It seems to me that B2G would ultimately want that anyway.
>
> A lot of the pushback from non-Firefox application authors seems to boil
> down to "we have a lot of old crufty C++ and there isn't the manpower to
> get it up to the current quality standard required for m-c" and/or
> "there isn't enough interest from the Firefox side of things in
> including code in m-c that Firefox doesn't require itself". Again, B2G
> implies (to me) that both of those are going to have to change going
> forward. A smartphone that can't access corporate email accounts is not
> going to be appealing to a large segment of the market for smartphones.

That doesn't mean that we need to get our current LDAP code up to m-c
quality, or include it in Firefox.  (Or, more accurately, Gecko?)

We could rewrite it in Javascript.

We could run similar functionality on a (possibly Mozilla-owned) server.

We could tell B2G users that they should be using webmail.  (And help
push that arena forward, perhaps by offering an easy-to-install
web-based front end to IMAP/SMTP servers.)

I, for one, would love to hear from the B2G folks about what their
non-SMS messaging plans are, but I suspect they are kinda busy these
days, and might not have had time to formulate any yet.  :)

Later,
Blake.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Steve Wendt
On 1/19/2012 3:12 PM, Blake Winton wrote:

> That doesn't mean that we need to get our current LDAP code up to m-c
> quality, or include it in Firefox. (Or, more accurately, Gecko?)
>
> We could rewrite it in Javascript.

Pushing everything to Javascript seems like a recipe for disaster; there
have been plenty of cons listed in this thread.

> We could run similar functionality on a (possibly Mozilla-owned) server.
>
> We could tell B2G users that they should be using webmail. (And help
> push that arena forward, perhaps by offering an easy-to-install
> web-based front end to IMAP/SMTP servers.)

Seriously?  That's just inviting failure.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Henri Sivonen
In reply to this post by Zack Weinberg-2
On Fri, Jan 20, 2012 at 12:31 AM, Zack Weinberg <[hidden email]> wrote:
> A lot of the pushback from non-Firefox application authors seems to boil
> down to "we have a lot of old crufty C++ and there isn't the manpower to get
> it up to the current quality standard required for m-c" and/or "there isn't
> enough interest from the Firefox side of things in including code in m-c
> that Firefox doesn't require itself".

I think mixing non-Firefox apps into this is broadens the problem in a
way that doesn't help with solving the actual problem. The actual
problem is 3rd-party native code touching the vtables of native code
shipped in Firefox (not Gecko-based app but *Firefox* specifically).

Since we aren't talking about getting rid of XPCOM altogether, we
could lock down the symbol exports and external dll load paths in
Firefox so that we'd no longer support 3rd-party native code touching
vtables shipped in Firefox directly (i.e. 3rd-party native code would
have to talk to native code contained in Firefox through a C-to-C API
[we have NPAPI in this category already], through C and jsctypes or so
that there's always XPConnected JS between a Mozilla-supplied C++
XPCOM object and a 3rd-party C++ XPCOM object [as Bobby suggested in
the other thread]) and still let non-Firefox Gecko-based apps use
XPCOM C++-to-C++.

In particular, when the "old crufty C++" is part of the build of the
non-Firefox Gecko-based app, it could continue to touch Gecko vtables
as much as it needs to if the non-Firefox app ships its own Gecko and
compiles Gecko and the additional app-specific C++ code together. Even
in this scenario, we could still even shorten IIDs and stop revising
them.

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Brian Smith-31
In reply to this post by Zack Weinberg-2
Zack Weinberg wrote:
> On 2012-01-18 12:08 AM, Mike Hommey wrote:
> > Do you suggest that things like the ldap client implementation
> > would need to be in m-c's libxul?
>
> I suppose I do.  It seems to me that B2G would ultimately want that
> anyway.

> A lot of the pushback from non-Firefox application authors seems to
> boil down to "we have a lot of old crufty C++ and there isn't the
> manpower to get it up to the current quality standard required for
> m-c" and/or "there isn't enough interest from the Firefox side of
> things in including code in m-c that Firefox doesn't require itself".

I am strongly on that side of the fence. We can't afford to include and maintain all kinds of libraries that some extension might maybe need sometime, beyond what we currently do. (Like I mentioned in the NSS/NSPR thread, it doesn't even seem realistic to me to continue indefinitely supporting many of the unused-by-Firefox code we currently ship.)

> Again, B2G implies (to me) that both of those are going to have to
> change going forward.  A smartphone that can't access corporate
> email accounts is not going to be appealing to a large segment of
> the market for smartphones.

Are we are going to try to standardize web APIs for LDAP/IMAP/SMTP/POP? Are we going to write an irreplaceable native code mail client for B2G? AFAICT, the answer to both of those questions is "no." I think, for B2G, we're going to have to provide a way to allow HTML5 apps to create raw socket connections, so that a pure HTML5 email application can do SMTP, IMAP, POP, and/or LDAP. (Who exactly is going to write the first pure JS email application that can do SMTP, IMAP, POP, and LDAP is another question. I guess this might be a very practical use case for C -> JS compilers.)

- Brian
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Brian Smith-31
In reply to this post by Steve Wendt
Steve Wendt wrote:
> On 1/19/2012 3:12 PM, Blake Winton wrote:
>
> > That doesn't mean that we need to get our current LDAP code up to
> > m-c quality, or include it in Firefox. (Or, more accurately, Gecko?)
> >
> > We could rewrite it in Javascript.
>
> Pushing everything to Javascript seems like a recipe for disaster;
> there have been plenty of cons listed in this thread.

AFAICT, there is no such thing as an addon or extension API in B2G at all. Every app is to be a regular HTML5 web app, that you will be able to run in the desktop browser too. They will use new web APIs that haven't been standardized (or even created) yet, with some way of handling permissions so that the user can let web apps he/she trusts do things that currently our platform doesn't allow because it is too dangerous to let any web app do them by default.

Also, keep in mind that in B2G, the user is supposed to be able to replace any built-in app with his own app (except maybe safety-critical things like the dialer). And, ideally, the built-in apps wouldn't have any advantage over user-created apps--in particular, no special access to ANY kind of API (LDAP or otherwise). The best way to ensure that is to have all the built-in apps, including *especially* the default email client, be pure HTML5 apps.

(I do agree that SMTP/IMAP/POP/LDAP email is a must-have for any serious B2G phone.)

- Brian
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Robert Kaiser
In reply to this post by Zack Weinberg-2
Henri Sivonen schrieb:
> Since we aren't talking about getting rid of XPCOM altogether, we
> could lock down the symbol exports and external dll load paths in
> Firefox so that we'd no longer support 3rd-party native code touching
> vtables shipped in Firefox directly (i.e. 3rd-party native code would
> have to talk to native code contained in Firefox through a C-to-C API
> [we have NPAPI in this category already]

They'll go and use Windows Dll hooking facilities and hook their
libraries directly into our process, which is much worse than XPCOM as
there are no version checks for any interfaces at all there. That said,
a lot of 3rd-party software is already doing that anyhow and causing us
in the crash analysis department a lot of grief.

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Robert Kaiser
In reply to this post by Zack Weinberg-2
Zack Weinberg schrieb:
> A smartphone that can't access corporate email accounts is not
> going to be appealing to a large segment of the market for smartphones.

Do you suppose we should define open web standards for accessing LDAP,
IMAP, maybe POP, for sure MS Exchange Server from web apps in a generic
way? If so, putting those things into Gecko makes sense. If not, then it
has to be reimplemented in JS for to be available in B2G, as AFAIK
everything any app in B2G does must be available to any web app
following open standards or at least spec that are on their way to
becoming such standards (see WebAPI).
I could be mistaken, but that's how I take the mission of this whole
project.

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Henri Sivonen
In reply to this post by Robert Kaiser
On Fri, Jan 20, 2012 at 5:11 PM, Robert Kaiser <[hidden email]> wrote:

> Henri Sivonen schrieb:
>
>> Since we aren't talking about getting rid of XPCOM altogether, we
>> could lock down the symbol exports and external dll load paths in
>> Firefox so that we'd no longer support 3rd-party native code touching
>> vtables shipped in Firefox directly (i.e. 3rd-party native code would
>> have to talk to native code contained in Firefox through a C-to-C API
>> [we have NPAPI in this category already]
>
>
> They'll go and use Windows Dll hooking facilities and hook their libraries
> directly into our process, which is much worse than XPCOM as there are no
> version checks for any interfaces at all there.

How does Chrome cope with this? Their source is also available, so
presumably 3rd parties might think they can use their header files,
etc.

> That said, a lot of
> 3rd-party software is already doing that anyhow and causing us in the crash
> analysis department a lot of grief.

Right. Version check didn't save us with the Oracle Single Sign-On
thing, for example.

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Zack Weinberg-2
In reply to this post by Zack Weinberg-2
On 2012-01-20 12:04 AM, Henri Sivonen wrote:

> On Fri, Jan 20, 2012 at 12:31 AM, Zack Weinberg<[hidden email]>  wrote:
>> A lot of the pushback from non-Firefox application authors seems to boil
>> down to "we have a lot of old crufty C++ and there isn't the manpower to get
>> it up to the current quality standard required for m-c" and/or "there isn't
>> enough interest from the Firefox side of things in including code in m-c
>> that Firefox doesn't require itself".
>
> I think mixing non-Firefox apps into this is broadens the problem in a
> way that doesn't help with solving the actual problem. The actual
> problem is 3rd-party native code touching the vtables of native code
> shipped in Firefox (not Gecko-based app but *Firefox* specifically).

It may not help with the technical problem all that much, but making
sure we take the needs of non-Firefox Gecko-based apps into account
helps with the *social* problem which is that we have this ridiculous
laser focus on The Web which is actually *hurting* efforts to make The
Web eat the desktop space.

> Since we aren't talking about getting rid of XPCOM altogether

Oh, but I most definitely am.

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Zack Weinberg-2
In reply to this post by Robert Kaiser
On 2012-01-20 7:14 AM, Robert Kaiser wrote:
> Zack Weinberg schrieb:
>> A smartphone that can't access corporate email accounts is not
>> going to be appealing to a large segment of the market for smartphones.
>
> Do you suppose we should define open web standards for accessing LDAP,
> IMAP, maybe POP, for sure MS Exchange Server from web apps in a generic
> way?

I haven't thought about this in great detail.  Long term, I prefer the
idea of finding some way to give web JS safe access to raw sockets; that
makes the web platform much more powerful, means we have less C++
exposed to data from the network, allows experimentation with entirely
new wire protocols, etc.

That is a really hard security problem, though; open standard web APIs
for commonly used protocols now might be the path of least resistance.

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Robert Kaiser
In reply to this post by Robert Kaiser
Henri Sivonen schrieb:
> On Fri, Jan 20, 2012 at 5:11 PM, Robert Kaiser<[hidden email]>  wrote:
>> They'll go and use Windows Dll hooking facilities and hook their libraries
>> directly into our process, which is much worse than XPCOM as there are no
>> version checks for any interfaces at all there.
>
> How does Chrome cope with this? Their source is also available, so
> presumably 3rd parties might think they can use their header files,
> etc.

Hmm, I have no idea, have never talked to them.

>> That said, a lot of
>> 3rd-party software is already doing that anyhow and causing us in the crash
>> analysis department a lot of grief.
>
> Right. Version check didn't save us with the Oracle Single Sign-On
> thing, for example.

Exactly. And a ton of others, esp. with "Security Suites".

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Henri Sivonen
On Fri, Jan 20, 2012 at 6:01 PM, Robert Kaiser <[hidden email]> wrote:
>>> That said, a lot of
>>> 3rd-party software is already doing that anyhow and causing us in the
>>> crash
>>> analysis department a lot of grief.
>>
>> Right. Version check didn't save us with the Oracle Single Sign-On
>> thing, for example.
>
> Exactly. And a ton of others, esp. with "Security Suites".

So intentionally exposing XPCOM doesn't really help, since 3rd parties
crash us anyway.

What *might* help with DLL injection, though, would be C APIs that the
3rd-party DLLs could use. They could still corrupt memory, but at
least they wouldn't crash due to vtable changes.

Have we ever asked the "security suite" vendors for a list of things
they want to accomplish when they inject code into Firefox and
evaluated whether those use case could be satisfied with reasonable
effort by a C API made specifically for "security suite" integration?
That is, what kind of stable API would it take to make the "security
suite" vendors agree not to poke at Firefox's vtables?

(Unfortunately, "security suites" probably want to get at user-private
data, so having an API that exposes the private data to "security
suites" would probably make it super easy for malware to tap into the
private data feed, too. But then, malware can already get to plenty of
private data, so an explicit API probably wouldn't make things worse.
Maybe we could have a C callback-based API that accepts only one
function pointer per callback, so if malware manages to register its
callbacks first, the "security suite" would fail to register its
callbacks and could whine about it.)

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Boris Zbarsky
In reply to this post by Robert Kaiser
On 1/20/12 4:47 PM, Henri Sivonen wrote:
> How does Chrome cope with this? Their source is also available, so
> presumably 3rd parties might think they can use their header files,
> etc.

For their chrome (supervisor) process, I don't know.

For their renderer processes, specifically on Windows, they start the
process in a "stopped" state of some sort, go through the process memory
before it starts running and block some set of DLLs trying to hook into
it (I think they started with a whitelist but had to switch to a
blacklist because apparently hooking into other processes is _very_
common on Windows), then actually start the process.

Or at least they did something like this back about two years ago, if I
understood correctly at the time.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Henri Sivonen
On Sun, Jan 22, 2012 at 1:48 PM, Boris Zbarsky <[hidden email]> wrote:

> On 1/20/12 4:47 PM, Henri Sivonen wrote:
>>
>> How does Chrome cope with this? Their source is also available, so
>> presumably 3rd parties might think they can use their header files,
>> etc.
>
>
> For their chrome (supervisor) process, I don't know.
>
> For their renderer processes, specifically on Windows, they start the
> process in a "stopped" state of some sort, go through the process memory
> before it starts running and block some set of DLLs trying to hook into it
> (I think they started with a whitelist but had to switch to a blacklist
> because apparently hooking into other processes is _very_ common on
> Windows), then actually start the process.

Is the sandboxing a prerequisite for this? Is this something that
could be applied to Firefox in the short term by making a small exe
bootstrap the real Firefox process like this?

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Mike Hommey
On Mon, Jan 23, 2012 at 11:13:18AM +0200, Henri Sivonen wrote:

> On Sun, Jan 22, 2012 at 1:48 PM, Boris Zbarsky <[hidden email]> wrote:
> > On 1/20/12 4:47 PM, Henri Sivonen wrote:
> >>
> >> How does Chrome cope with this? Their source is also available, so
> >> presumably 3rd parties might think they can use their header files,
> >> etc.
> >
> >
> > For their chrome (supervisor) process, I don't know.
> >
> > For their renderer processes, specifically on Windows, they start the
> > process in a "stopped" state of some sort, go through the process memory
> > before it starts running and block some set of DLLs trying to hook into it
> > (I think they started with a whitelist but had to switch to a blacklist
> > because apparently hooking into other processes is _very_ common on
> > Windows), then actually start the process.
>
> Is the sandboxing a prerequisite for this? Is this something that
> could be applied to Firefox in the short term by making a small exe
> bootstrap the real Firefox process like this?

We already do something like this, except we don't check what is already
loaded, we only block further loadings. And that doesn't really require
sandboxing.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Ted Mielczarek-2
In reply to this post by Henri Sivonen
On Fri, Jan 20, 2012 at 10:47 AM, Henri Sivonen <[hidden email]> wrote:
>> They'll go and use Windows Dll hooking facilities and hook their libraries
>> directly into our process, which is much worse than XPCOM as there are no
>> version checks for any interfaces at all there.
>
> How does Chrome cope with this? Their source is also available, so
> presumably 3rd parties might think they can use their header files,
> etc.

I would assume that Chrome has less of a problem with this because
AFAIK they've never exposed a C++ API (not counting NPAPI). With Gecko
exposing XPCOM, it's not that hard to get a hold of various internal
bits of our engine and cast your way to certain doom. In Chrome, I
don't know how you'd get a hold of their internal C++-implemented
classes without grovelling around in the processes' address space.

-Ted
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: The purpose of binary components

Benjamin Smedberg
In reply to this post by Brian Smith-31
On 1/20/12 4:44 AM, Brian Smith wrote:
>
> AFAICT, there is no such thing as an addon or extension API in B2G at all. Every app is to be a regular HTML5 web app, that you will be able to run in the desktop browser too. They will use new web APIs that haven't been standardized (or even created) yet, with some way of handling permissions so that the user can let web apps he/she trusts do things that currently our platform doesn't allow because it is too dangerous to let any web app do them by default.
This is not precisely true, there will almost certainly be an extension
API (either jetpack or something similar) for the B2G browser at least.
But it will not involve native code at all, just HTML/JS.

--BDS

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345