309636 - Need special mechanism to upgrade bundled Java Embedding Plugin?

Status: RESOLVED WORKSFORME

(Plugins Graveyard :: Java (Java Embedding Plugin), defect)

Description

[Steven Michaud [:smichaud] (Retired)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920
Build Identifier: na

I'm trying to start a discussion on whether or not this is possible, and if it
_is_ possible how it might be done.

The motivation is to find a way to upgrade the bundled copy of the Java
Embedding Plugin without releasing a new version of Firefox.

The Java Embedding Plugin uses (must use) many low-level, undocumented APIs --
so updates from Apple (particularly Java updates) are more likely to break the
JEP than an ordinary program.  Apple has never tested Mozilla.org browsers
with the Java Embedding Plugin (though work is in progress to change this).
And they tend to be very secretive about their internal development processes
(though people are trying to find a way around this for JEP "show-stoppers").

All of this makes it uncomfortably likely that Apple will release a minor
update that (basically) breaks OS X Java support on a released version of
Firefox.  The best solution is to convince Apple not to do this.  But mistakes
can be made with even the best of intentions.  It won't be the end of the
world if Mozilla.org has to release a new Firefox version to deal with this
kind of problem.  But it would also be good to have a less disruptive
alternative.

I think a particularly "sweet" alternative would be to have users install new
versions of the Java Embedding Plugin (to their distro's
Contents/MacOS/plugins/ directory) like they do extensions.  The installer
could be hosted by Mozilla.org, and users could be directed to it as
necessary.

For more information on the Java Embedding Plugin:

http://javaplugin.sourceforge.net/

For some background on this discussion see bug 308549.



Reproducible: Didn't try

Comment 1

[Steven Michaud [:smichaud] (Retired)]

I just stumbled across XPInstall:

http://developer.mozilla.org/en/docs/Using_XPInstall_to_Install_Plugins

Would that be a better way to upgrade embedded versions of the Java Embedding
Plugin than an extension installer?

Would it make sense (and have some advantage) to somehow combine the two?

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

One thing that I found interesting is that the Fx software update from 1.5b1 to
1.5b2 did update the JEP from 0.9.3+b to 0.9.4+a, which seems to indicate that
the sw update mechanism is a viable way to provide JEP updates on stable Fx
branches if Apple ever breaks things again. (AIUI, one of the goals of the
system is to be able to deliver updates that may only be needed on one platform,
etc., without necessitating a full Fx release.)

What puzzles me is that the branch nightly build update channel never did update
the JEP.

Since Steven has mentioned at least two other potential? avenues, tweaking the
summary.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Auto update is a perfectly good way to upgrade the bundled Java Embedding
Plugin.  And I think it's entirely reasonable to issue a new minor release if
Apple breaks the JEP again -- minor upgrades will happen regardless, for
various reasons.

But it is (or might be) nice to have a less disruptive alternative, which
didn't require a full "new" version.  I opened this bug to discuss one way it
might be done.  If other ways come up, it'd make sense to discuss them here,
too.

This isn't urgent -- we already have a good way of dealing with this kind of
problem.  But something useful might turn up.

I've changed the description yet again, to indicate the exploratory nature of
this bug, and its lack of urgency.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

One thing to note here about upgrading: while it appears Fx software update will properly update an in-app JEP (comment 2) in normal cases, I've just verified via the 1.5.0.1 "patch update" that if a user has removed the in-app JEP, it does not get upgraded.  (The files are no longer there, and I guess it stands to reason that the binary patching system can't patch a few bytes into non-existant files.)

In normal cases, again, this is not a problem, but in situations like those with Firefox 1.5 (where bug 313807 rendered Firefox completely unuseable for large numbers of Mac users, and where the suggestion of removing the in-app JEP and installing the available updated JEP version into (~)/Library/Plugins was given not only in Bugzilla but also far and wide across the Mac web), there's certainly a problem of some sort.  Those users are fine in the short term--they do have what is today the latest JEP from their "manual update"--but in two weeks when smichaud delivers a JEP that stops causing the (top)crasher in bug 312062/bug 324281, these users will never get the fix in Fx 1.5.0.x.  Nor will they get any other JEP update after that, ever, unless they download the JEP updates manually or download a full Firefox install.

And, frankly--with no offense to smichaud intended--the hacky nature of the work required to enable modern Java in a non-Apple Mac browser, the history of Java updates breaking the JEP, and the constraints of the various Moz-Apple-JEP product leadtimes and release cycles, I fully expect in the future to see more situations where large groups of Mac Gecko users will either be faced with a non-functioning or crashing browser or manually remove their in-app JEP (and then run into this same problem). 

Maybe the loss of future JEP updates for users who manually removed the in-app version to get a working browser is an acceptable consequence, maybe it's something that can be handled with release notes or updated website text, etc., but it does seem to me to be something that should be considered and worked out.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

I agree with Smokey.  And I think the obvious way out of the dilemma is for
Firefox's upgrade mechanism is to upgrade the JEP even when someone has
manually removed it.

I've also been telling people (those who need to upgrade their JEP) to remove
the old JEP from the distro and to install the new JEP to /Library/Internet
Plug-Ins/.  When users do upgrade manually, it's really best to install to
/Library/Internet Plug-Ins/ and remove older JEPs from the Firefox (or Camino)
distros that you're currently using.  Especially if they have multiple copies
of Firefox and/or Camino.

Judging by past experience, the (occasional) need for manual upgrades will
never disappear.  I'd like to make this process less daunting, so I plan (in
my not so voluminous spare time) to create an installer for the JEP.  The
installer will install to /Library/Internet Plug-Ins/.  If I have the time,
I'd also like to make it be able to do the following -- if you drag a Firefox
(or Camino) distro onto the installer, it either upgrades the distro's own JEP
or removes it (arguments can be made on both sides).

By the way, I don't take offense at the JEP being called a hack.  It is.  Only
a hack would be able to accomplish what it has done.  But it does work quite
well.  And (I think) it keeps getting better :-)

Comment 6

[Chris McAfee]

the JEP is a *workaround* for Apple's failure to address java support
for non-WebKit-derived browsers.  This has been a really useful hack,
so ... we need to keep it going.

Maybe there could be some auto-detect mechanism that would 
check to see if "java runs ok" and then would try to update
the plugin if not?  Or have an easy way for the user to
"just click here" to try the latest version.  An installer would
help make this process more streamlined.

Comment 7

[Mark Mentovai]

I'm a little surprised that auto-update doesn't download the full version instead of the delta if there are files missing.  Was this intentional?

Comment 8

[Benjamin Smedberg]

No, doing a full download if the partial fails is the intentional behavior. Can we file a separate bug with good steps to reproduce on that issue?

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #8)
> No, doing a full download if the partial fails is the intentional behavior. Can
> we file a separate bug with good steps to reproduce on that issue?

After seeing that yesterday, I manually invoked the software update and it did download the full 8.4 MB version and update properly (including the latest JEP).  That was the third time software update had run and downloaded something since 1.5.0.1 updates became available, so the second instance was either a re-attempt to download the delta or a failed update of the full version (this entire "update cycle" happened over the course of several days, with the notifications of available/downloaded updates always occuring when I was in the middle of something, so I wasn't paying close enough attention, obviously).

Since then, I've tried several times to replicate the situation, and each time 
1) I get an "update failed, downloading full update" dialogue after the delta updater runs at next launch and finds the JEP missing (I never saw this dialogue before, but the fact that it appears behind the main browser window could have caused me to overlook it) and 
2) the full updater then downloads and installs correctly on the next launch.

I'm still not sure what happened with my initial cycle, but I've been unable to reproduce it under controlled, single-day update cycles, so I apologize for raising the false alarm here.  

And, while it may be inconvenient for folks on dialup or metered connections, I'm sufficiently content for the purposes of this bug with the fact that the delta updater fails on updating a JEP-less build and downloads the full update with the latest JEP.

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Steven, is it OK to close this now?  We seem to have gotten on OK for 2+ years now just using normal app updates :)

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Works for me :-)