removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Josh Aas-3
We're currently planning to remove OJI, LiveConnect, and the XPCOM
plugin API from Gecko 1.9.2. We've worked hard to get to a point where
this would be possible and I believe we can make these changes in
Gecko 1.9.2.

We are planning to remove those components because they are largely
unmaintained, they have few consumers, and there are better
alternatives.

To put this change in perspective in terms of a timeline, the earliest
a browser with those changes would ship would be approximately Q2
2010.

There are three major consumers of these components - Sun's Java
plugin, Steven Michaud's JEP, and the Real player. Sun has worked with
us to develop a new Java plugin based on NPAPI and NPRuntime, removing
their dependency on OJI/LiveConnect and the XPCOM plugin API. This new
plugin is already available for Windows and Linux and will be coming
to Mac OS X soon. When the new plugin arrives for Mac OS X it will be
an alternative to the JEP. As for Real player, we are working with
Real to move them to NPAPI and NPRuntime as well.

Our plan for Java on Mac OS X is to ship the JEP in Firefox 3.5, which
should be supported until around Q4 2010. The Gecko 1.9.2 branch will
not support JEP. It will use the new Java plugin from Sun and Apple,
which will be available before a browser based on Gecko 1.9.2 becomes
available.

The question at hand now is when to actually commit the changes to the
1.9.2 branch. The removal is not simple and the improvements we plan
to make once those components are out of the way will take time
(including major simplification and cleanup in our plugins module).
This is not a change we can make at the last minute. I'm inclined to
commit the removal in April but I'd appreciate feedback on timing.

The argument against committing now is that we'll go for a period of
time on the trunk without a Java plugin on Mac OS X and without Real
player on all platforms. However, we are not losing regression
coverage because both plugins are being replaced entirely and users
that actually need those capabilities can use Firefox 3.5. I can't
comment further on the timelines for re-gaining support in Gecko 1.9.2
but they are well within the Gecko 1.9.2 development time frame.

The argument for committing now is that this is a major change, we
need time and we're not losing coverage of plugins that we'll be
supporting when we ship. It also gives plugin developers more time to
develop against the exact set of plugin APIs that will be available to
them when we ship.

Fun fact: a basic removal patch for this stuff is ~6MB and growing.

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Kevin Brosnan
On Fri, Mar 20, 2009 at 20:17,  <[hidden email]> wrote:

> We're currently planning to remove OJI, LiveConnect, and the XPCOM
> plugin API from Gecko 1.9.2. We've worked hard to get to a point where
> this would be possible and I believe we can make these changes in
> Gecko 1.9.2.
>
> We are planning to remove those components because they are largely
> unmaintained, they have few consumers, and there are better
> alternatives.
>
> To put this change in perspective in terms of a timeline, the earliest
> a browser with those changes would ship would be approximately Q2
> 2010.
>
> There are three major consumers of these components - Sun's Java
> plugin, Steven Michaud's JEP, and the Real player. Sun has worked with
> us to develop a new Java plugin based on NPAPI and NPRuntime, removing
> their dependency on OJI/LiveConnect and the XPCOM plugin API. This new
> plugin is already available for Windows and Linux and will be coming
> to Mac OS X soon. When the new plugin arrives for Mac OS X it will be
> an alternative to the JEP. As for Real player, we are working with
> Real to move them to NPAPI and NPRuntime as well.
>
> Our plan for Java on Mac OS X is to ship the JEP in Firefox 3.5, which
> should be supported until around Q4 2010. The Gecko 1.9.2 branch will
> not support JEP. It will use the new Java plugin from Sun and Apple,
> which will be available before a browser based on Gecko 1.9.2 becomes
> available.
>
> The question at hand now is when to actually commit the changes to the
> 1.9.2 branch. The removal is not simple and the improvements we plan
> to make once those components are out of the way will take time
> (including major simplification and cleanup in our plugins module).
> This is not a change we can make at the last minute. I'm inclined to
> commit the removal in April but I'd appreciate feedback on timing.
>
> The argument against committing now is that we'll go for a period of
> time on the trunk without a Java plugin on Mac OS X and without Real
> player on all platforms. However, we are not losing regression
> coverage because both plugins are being replaced entirely and users
> that actually need those capabilities can use Firefox 3.5. I can't
> comment further on the timelines for re-gaining support in Gecko 1.9.2
> but they are well within the Gecko 1.9.2 development time frame.
>
> The argument for committing now is that this is a major change, we
> need time and we're not losing coverage of plugins that we'll be
> supporting when we ship. It also gives plugin developers more time to
> develop against the exact set of plugin APIs that will be available to
> them when we ship.
>
> Fun fact: a basic removal patch for this stuff is ~6MB and growing.
>
> -Josh Aas
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>

Is there any (easy) way to test the plugins at
http://plugindoc.mozdev.org/windows-all.html for use of code that
would be effected by this change? Or would a direct email to the
developers, if they can be located make sense? I know that these
plugins represent a fractional percentage of plugin usage. However
making a good faith effort that alerts them to the change as early as
possible makes sense as they may not closely follow NPAPI development.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Igor Bukanov-2
In reply to this post by Josh Aas-3
2009/3/21  <[hidden email]>:
> This is not a change we can make at the last minute. I'm inclined to
> commit the removal in April but I'd appreciate feedback on timing.

The liveconnect, which uses C, currently includes non-public
SpiderMonkey headers. Since SpiderMonkey uses C++ this requires
workarounds in the headers to hide C++ constructions incompatible with
C to make sure that liveconnect compiles.

With liveconnect removed those headers would inevitably quickly became
C++ only on 1.9.2 branch. That would mean that backports to 1.9.1 may
require extra efforts. Given the amount of 1.9.1 blockers it would be
nice to avoid any potential additional work until, say, RC1. So at
least with liveconnect I suggests to wait with its removal until
Firefox 3.5 RC1.

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

gNeandr-3
In reply to this post by Josh Aas-3
There have been postings to other groups (eg. m.d.ext) to ask about the
current/future support of JAVA.

I have discussed with a pure JAVA base app
(http://www.finchsync.com/index.html [FS]) for sync TB/AB and ICS data
(Lightning, Reminderfox etc) to change that application having a Mozilla
based support, at least to use the new methods to access TB/AB directly.
That would require to adapt Mozilla code with main parts of JAVA based
FS or to build an extension and "encapsulated" parts of FS (eg. using
their sync based on on .NET etc).

QQ: With the mentioned change for Gecko 1.9.2 can anybody recommand
which is the 'best' way to get that done? Any suggestions?

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Josh Aas-3
In reply to this post by Josh Aas-3
On Mar 20, 10:27 pm, Kevin Brosnan <[hidden email]> wrote:
> Is there any (easy) way to test the plugins athttp://plugindoc.mozdev.org/windows-all.htmlfor use of code that
> would be effected by this change? Or would a direct email to the
> developers, if they can be located make sense? I know that these
> plugins represent a fractional percentage of plugin usage. However
> making a good faith effort that alerts them to the change as early as
> possible makes sense as they may not closely follow NPAPI development.

Good idea, I'll look into notifying them of this change.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Josh Aas-3
In reply to this post by Josh Aas-3
On Mar 21, 4:07 am, Igor Bukanov <[hidden email]> wrote:

> 2009/3/21  <[hidden email]>:
>
> > This is not a change we can make at the last minute. I'm inclined to
> > commit the removal in April but I'd appreciate feedback on timing.
>
> The liveconnect, which uses C, currently includes non-public
> SpiderMonkey headers. Since SpiderMonkey uses C++ this requires
> workarounds in the headers to hide C++ constructions incompatible with
> C to make sure that liveconnect compiles.
>
> With liveconnect removed those headers would inevitably quickly became
> C++ only on 1.9.2 branch. That would mean that backports to 1.9.1 may
> require extra efforts. Given the amount of 1.9.1 blockers it would be
> nice to avoid any potential additional work until, say, RC1. So at
> least with liveconnect I suggests to wait with its removal until
> Firefox 3.5 RC1.
>
> Igor

That is fine with me, I'll make sure we wait until at least 3.5 RC1 to
remove LiveConnect.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Robert Kaiser
In reply to this post by Josh Aas-3
[hidden email] wrote:
> The question at hand now is when to actually commit the changes to the
> 1.9.2 branch.

Should be before the first Alpha IMHO, so that anyone doing/starting
stuff based on any "official" prerelease wouldn't rely on those
functionalities.

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Peter Weilbacher
In reply to this post by Josh Aas-3
On 21.03.09 01:17, [hidden email] wrote:
> There are three major consumers of these components - Sun's Java
> plugin, Steven Michaud's JEP, and the Real player. Sun has worked with
> us to develop a new Java plugin based on NPAPI and NPRuntime, removing
> their dependency on OJI/LiveConnect and the XPCOM plugin API. This new
> plugin is already available for Windows and Linux

Can you be a bit more specific? Which version(s) of the Sun plugin are
NPAPI-based?
    Peter.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Boris Zbarsky
In reply to this post by Josh Aas-3
[hidden email] wrote:
> To put this change in perspective in terms of a timeline, the earliest
> a browser with those changes would ship would be approximately Q2
> 2010.

Is that seriously how late the release after 1.9.1 is planned for?
That's rather sad-making.  I was hoping we'd do a Gecko release before
that.  :(  Was there a discussion I missed somewhere?

> The argument against committing now is that we'll go for a period of
> time on the trunk without a Java plugin on Mac OS X and without Real
> player on all platforms. However, we are not losing regression
> coverage because both plugins are being replaced entirely and users
> that actually need those capabilities can use Firefox 3.5.

We might be using trunk testing coverage in general, though, if people
can't use it because sites they rely on don't work without Java....  Do
we have any data on this?

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Josh Aas-3
On Mar 22, 5:18 pm, Boris Zbarsky <[hidden email]> wrote:
> [hidden email] wrote:
> > To put this change in perspective in terms of a timeline, the earliest
> > a browser with those changes would ship would be approximately Q2
> > 2010.
>
> Is that seriously how late the release after 1.9.1 is planned for?
> That's rather sad-making.  I was hoping we'd do a Gecko release before
> that.  :(  Was there a discussion I missed somewhere?

This is an estimate of mine, I haven't heard any formal plans. Planned
is < actual in almost every case anyway, and Q2 2010 is less than 1
year after 1.9.1. I'd be extremely surprised if we saw a 1.9.2 release
before March of 2010.

> > The argument against committing now is that we'll go for a period of
> > time on the trunk without a Java plugin on Mac OS X and without Real
> > player on all platforms. However, we are not losing regression
> > coverage because both plugins are being replaced entirely and users
> > that actually need those capabilities can use Firefox 3.5.
>
> We might be using trunk testing coverage in general, though, if people
> can't use it because sites they rely on don't work without Java....  Do
> we have any data on this?

I think the number of Mac OS X trunk nightly users that rely on Java
so much that they can't occasionally use Firefox 3.5 for a bit is very
small. I'm not worried about their impact on overall nightly testing
coverage. I have no idea where we'd get data on that.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Boris Zbarsky
[hidden email] wrote:
> I think the number of Mac OS X trunk nightly users that rely on Java
> so much that they can't occasionally use Firefox 3.5 for a bit is very
> small. I'm not worried about their impact on overall nightly testing
> coverage. I have no idea where we'd get data on that.

We can start by getting data on how many trunk OSX users we have to
start with....  Then we could consider widely asking this question and
see what responses we get from them.

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Boris Zbarsky
In reply to this post by Josh Aas-3
[hidden email] wrote:
> I think the number of Mac OS X trunk nightly users that rely on Java
> so much that they can't occasionally use Firefox 3.5 for a bit is very
> small. I'm not worried about their impact on overall nightly testing
> coverage. I have no idea where we'd get data on that.

And it's not just "occasionally use Firefox 3.5 for a bit".  It's a
matter of having to maintain a separate profile for that use (because
going back and forth across versions on a given profile is NOT something
one ever wants to do), remembering to always start Firefox 3.5 when
going to some particular sites, remembering to not use it for going to
other sites, having bookmarks and history forked, etc.

Basically, if there were even one site that needs me to use Java, I'd
not bother running trunk builds at all in the above setup.  It'd just be
too much pain.

I think none of the sites I care about in fact use Java, but I'm not a
good representative sample (e.g. 60+% of my web browsing is Bugzilla).

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Justin Dolske-2
On 3/22/09 7:05 PM, Boris Zbarsky wrote:
> [hidden email] wrote:
>> I think the number of Mac OS X trunk nightly users that rely on Java
>> so much that they can't occasionally use Firefox 3.5 for a bit is very
>> small. I'm not worried about their impact on overall nightly testing
>> coverage. I have no idea where we'd get data on that.

Crazy idea -- turn it off now, maybe just for a week or two, and see if
anyone screams bloody murder?

> Basically, if there were even one site that needs me to use Java, I'd
> not bother running trunk builds at all in the above setup. It'd just be
> too much pain.

Yeah. I'd guess that user are largely divided into 2 buckets... Those
that simply never encounter Java online, and those who use it frequently
(likely because their employer/school has some tool that requires it).
How big and how important that latter bucket is, I don't know.

FWIW, I disabled Java in my daily-use profile a long time ago. About the
only things I've run across (rarely) that need it are a few online
games, and demos on educational pages.

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Igor Bukanov-2
2009/3/23 Justin Dolske <[hidden email]>:
> About the
> only things I've run across (rarely) that need it are a few online games,
> and demos on educational pages.

Some banks use Java for netbanking and there are photo-sharing or
printing sites that use signed Java applet to implement multiple image
upload.

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Josh Aas-3
In reply to this post by Peter Weilbacher
On Mar 22, 3:48 pm, Peter Weilbacher <[hidden email]> wrote:

> On 21.03.09 01:17, [hidden email] wrote:
>
> > There are three major consumers of these components - Sun's Java
> > plugin, Steven Michaud's JEP, and the Real player. Sun has worked with
> > us to develop a new Java plugin based on NPAPI and NPRuntime, removing
> > their dependency on OJI/LiveConnect and the XPCOM plugin API. This new
> > plugin is already available for Windows and Linux
>
> Can you be a bit more specific? Which version(s) of the Sun plugin are
> NPAPI-based?
>     Peter.

The new NPAPI/NPRuntime-based Java plugin is available for Windows and
Linux starting with Java SE 6 Update 10.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

timeless-3
In reply to this post by Igor Bukanov-2
On Mon, Mar 23, 2009 at 5:27 AM, Igor Bukanov <[hidden email]> wrote:
> Some banks use Java for netbanking and there are photo-sharing or
> printing sites that use signed Java applet to implement multiple image
> upload.

My bank is one of those stupid banks. (It's a subsidiary of Danske
bank and the java requirement was introduced after Dasnke bought my
bank, so I'd imagine it's a feature of their somewhat widely spread
Nordic banking services).

It turns out for very basic operations if you're incredibly clever you
can find a mobile page that works, but it requires either speaking
some obscure language or speaking that obscure language and hacking
urls.

OTOH, as w/ bz, I'm not the target audience, since I can't run a
modern gecko on my mac anyway.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Robert Kaiser
In reply to this post by Josh Aas-3
[hidden email] wrote:

> On Mar 22, 5:18 pm, Boris Zbarsky<[hidden email]>  wrote:
>> [hidden email] wrote:
>>> To put this change in perspective in terms of a timeline, the earliest
>>> a browser with those changes would ship would be approximately Q2
>>> 2010.
>>
>> Is that seriously how late the release after 1.9.1 is planned for?
>> That's rather sad-making.  I was hoping we'd do a Gecko release before
>> that.  :(  Was there a discussion I missed somewhere?
>
> This is an estimate of mine, I haven't heard any formal plans. Planned
> is<  actual in almost every case anyway, and Q2 2010 is less than 1
> year after 1.9.1. I'd be extremely surprised if we saw a 1.9.2 release
> before March of 2010.

Note that the actual intention of the post-1.9.0 smaller-release plan
was to release more often, i.e. about every 6 months. Unfortunately we
largely failed to do that with 1.9.1 but maybe we manage to really
improve this and and come nearer towards the actual plan next time around.

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

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Peter Weilbacher
On 03/23/09 13:50, Robert Kaiser wrote:

> [hidden email] wrote:
>> This is an estimate of mine, I haven't heard any formal plans. Planned
>> is< actual in almost every case anyway, and Q2 2010 is less than 1
>> year after 1.9.1. I'd be extremely surprised if we saw a 1.9.2 release
>> before March of 2010.
>
> Note that the actual intention of the post-1.9.0 smaller-release plan
> was to release more often, i.e. about every 6 months. Unfortunately we
> largely failed to do that with 1.9.1 but maybe we manage to really
> improve this and and come nearer towards the actual plan next time around.

I thought the original plan was to release smaller changes more often in
minor releases, and at the same time work on Mozilla2. But I haven't heard
anything about Mozilla2 in the last few months. But I have missed an
annoucement where it was declared dead or postponed...
    Peter.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Dan Mosedale
Banned User
This post was updated on .
In reply to this post by Josh Aas-3
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: removing OJI, LiveConnect, and the XPCOM plugin API in Gecko 1.9.2

Josh Aas-3
On Mar 23, 9:50 am, Dan Mosedale <[hidden email]> wrote:

> On 3/20/09 5:17 PM, [hidden email] wrote:
>
> > We're currently planning to remove OJI, LiveConnect, and the XPCOM
> > plugin API from Gecko 1.9.2. We've worked hard to get to a point where
> > this would be possible and I believe we can make these changes in
> > Gecko 1.9.2.
>
> > We are planning to remove those components because they are largely
> > unmaintained, they have few consumers, and there are better
> > alternatives.
>
> What effect will this have on Gecko application extensions that contain
> Java code?  That they would need source-level changes?  That they would
> stop working entirely?

There are no functional regressions that I'm aware of, nor do I know
of any required code changes under the new plugin. You can even still
access Java classes from JS in the same way that it was possible
before iirc, though the details of that aren't clear to me. I don't
know much about that functionality, I just recall that it was
preserved. So as far as extensions relying on a particular Java plugin
goes, I don't think there are any issues.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12