Closed Bug 308549 Opened 16 years ago Closed 16 years ago
Apple's OS X 10
.3 Java Security Update breaks the Java Embedding Plugin
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.11) Gecko/20050728 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.11) Gecko/20050728 Apple's "Java Security Update" for Mac OS X 10.3.X, which was released today, breaks the Java Embedding Plugin (all versions). This update was made available via Software Update at the same time it was released, so many people may have downloaded it without quite realizing it. Apple never posted any announcement to their Java-Dev mailing list that they were working on a Java update for OS X 10.3.X, nor did they post any prerelease versions to their Developer Connection (to which I belong). Apple _did_ post pre-release versions of their "Java 1.3.1 and 1.4.2 Release 2" for OS X Tiger (10.4.X), which was also released today. The Java Embedding Plugin is compatible with the last pre-release version (DP4), and appears to also be compatible with the release. There is no workaround for the problem on OS X 10.3.X. If possible, please postpone downloading Apple's Java Security Update until I'm able to release an update to the Java Embedding Plugin that fixes this problem. I hope to do that in the next day or two. (The Java Embedding Plugin has been bundled with Camino, Firefox and SeaMonkey nightlies for several weeks, and is also included with Firefox 1.5 Beta 1.) This report was also posted at: http://sourceforge.net/tracker/index.php?func=detail&aid=1291312&group_id=107955&atid=649116 Reproducible: Always
> Apple _did_ post pre-release versions of their "Java 1.3.1 and 1.4.2 Release > 2" for OS X Tiger (10.4.X), which was also released today. The Java > Embedding Plugin is compatible with the last pre-release version (DP4), and > appears to also be compatible with the release. Actually, people using version 0.9.3 or earlier of the Java Embedding Plugin on Tiger will need (once more) to do the following at a Terminal prompt: touch "/Library/Internet Plug-Ins/MRJPlugin.plugin" This is needed to make the MRJPlugin.plugin's date later than that of Apple's (newly updated) "Java Applet Plugin Enabler".
For the 10.4 folks running nightlies/recent alphas and betas, does the internally-bundled MRJplugin need to be touched, or is that only for the stand-alone (/Library/Plug-ins) one? I'll confirm this to make it easier to find, and cc some folks.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> does the internally-bundled MRJplugin need to be touched No. > or is that only for the stand-alone (/Library/Plug-ins) one? Yes.
Do we need to make our browser always load the built-in plugin in preference to the Library/Plug-Ins one?
> Do we need to make our browser always load the built-in plugin in preference > to the Library/Plug-Ins one? Mozilla.org's Mac browsers have always (or at least for a long time) looked for plugins first in the distro's Contents/MacOS/plugins directory, then in ~/Library/Internet Plug-Ins/, then in /Library/Internet Plug-Ins/. The plugin host always takes the first plugin it finds that handles a given MIME type, and doesn't look any further. The last modification time (and the "touch" business) only becomes important if a given directory might contain more than one plugin that handles a given MIME type. I believe all this is correct, and shouldn't be changed. Yes, I suppose that always grabbing the latest plugin (if it's available) has its merits -- it would make _this_ problem a little (but only a little) easier to resolve. But I think this is trumped by knowing that, if the right stuff (and _only_ the right stuff) is in Contents/MacOS/plugins, you never have to worry about version mismatches, or behavior changes from version to version.
Sure, but there's a serious problem lurking here and I want to make sure it doesn't get swept under the rug. In a few months' time, we'll cut 1.5/1.0 releases that will be out there in the wild for a long time to come. It's evident that it's as easy as pie for Apple to break Java for us. I have no doubt that their changes are minor and easily worked around in the JEP itself, but that won't appease users stuck with a Java-less Firefox 1.5 when Apple decides to roll another update. So what do we do? Cut new releases of the browsers every time that happens, with fresh JEPs bundled? What happens to the folks that don't or won't upgrade? Now that the JEP lives inside the app package, we've effectively foreclosed users from installing newer JEPs in local plug-in folders. The only solution for is to delve into the app package, and that's beyond the skill sets of many users. There's gotta be a better way. Steven, when incompatibilities like this hit, do they ever require critical changes to the MRJ plugin? If the only thing that needs periodic maintenance is the JEP bundle, then perhaps the MRJ plugin could be modified to use the newest JEP it can find. I'd understand if that might put you in an uncomfortably tight spot with APIs, though. Maybe we should always go for the most recent plugin, even if MRJ has to be treated as a special case. Or maybe we should just provide and document a way to turn the MRJ off without killing plugins altogether, letting the user force a fallback to Java 1.3 in the event that an incompatibility such as this one crops up again.
I think there's only one good solution to this dilemma -- "we" have to convince Apple not to do this again with a minor update (major updates, like from Mac OS X 10.3.X to 10.4.X are a different matter). I don't think Apple did this deliberately. Rather, they just didn't (and don't) test with the Java Embedding Plugin. (And, because they didn't give any pre-releases to Developer Connection members, they didn't give _me_ a chance to test, either.) By myself, I'm just a minor player. But once the Java Embedding Plugin is included in (especially) Firefox, it's no longer in the same situation. I can't believe that Apple didn't test with recent released versions of Firefox (at least). I think "we" ... that is _you_ :-) ... need to convince Apple to add Firefox-plus-the-JEP (and maybe Camino-plus-the-JEP) to their test bed. (Once I've had a night's rest I'll say more about what we might do about this particular problem, now that it's happened.)
we know someone on the Java team (chris mcafee) who used to be fairly involved with having them do the right thing for us. we should try to poke him and see what happened this time around. anyone have his contact info?
Chris McAfee wrote me a while ago offering his help to test universal binaries of the Java Embedding Plugin. (I've been so busy with other things that I've had to put that off.) His position at Apple is "Java Release Engineer" ... so it sounds like he'd be just the right person to contact. I'll send you his email addresses (I have two of them) in private email. (Feel free to pass them around to others in mozilla.org.) It's probably alright for me to mention them here ... but just in case. Once things have quited down a bit (after I've released my new version), I'll write him myself, too. And once that new version is out (today or tomorrow), I'll have time for a detailed discussion, here, of what to do about this problem, and other problems with embedded copies of the Java Embedding Plugin that might arise in the future.
I've just released JEP 0.9.4, which fixes this problem. http://javaplugin.sourceforge.net/ > And once that new version is out (today or tomorrow), I'll have time for a > detailed discussion, here, of what to do about this problem, and other > problems with embedded copies of the Java Embedding Plugin that might arise > in the future. Let's hold this off until tomorrow, at least. I need a break :-)
I apologize for the non-heads-up about the 10.3 update, we were not allowed to preview anything. I have suggested to my group that we add JPE/Firefox to our internal testing suite, I agree it would be good not-to-break-this next time. I can continue some of this discussion in email, please send me email.
I think the best way to get JEP 0.9.4 to users of Firefox 1.5 Beta 1 and Camino 1.0 Alpha 1 is to land it on the trunk and the 1.8 and Camino-1.0 branches as soon as possible. Then users of these two distros who are running on OS X 10.3.X can be told to download the appropriate nightly. But I'm afraid 0.9.4 has some problems (though nothing severe), so I'm going to follow it pretty soon (sometime next week) with a 0.9.4+a "nightly". I've discovered a couple of occasional-crash bugs that (I think) are new since 0.9.3. I missed them in my rush to get 0.9.4 out the door. (There's also what I think might be a Camino bug (trunk and 1.0 builds only), which also happens with 0.9.3 and which I missed earlier -- Camino tends to crash (in mozilla.org browser code) when you quit it while a browser page is open that contains lots of applets. If possible, I'd also like to include a fix/workaround for this in 0.9.4+a.) Once 0.9.4+a is out, it, too should (I think) get onto the trunk and 1.8 and Camino-1.0 branches as soon as possible -- the better to test it and find whatever problem _it_ may have. (Ordinary Firefox users will, I think, find it equally difficult to install a new JEP to /Library/Internet Plug-Ins/ or to their distro's Contents/MacOS/plugins. So asking them to do either of these things is a non-starter.)
Here's an idea that should probably get its own bug, if it's at all feasible. But I'll mention it first here where a lot of the mozilla.org principals will see it: Is there any chance that the mechanism used (in Firefox) to install extensions could be used to install JEP updates to the distro's Contents/MacOS/plugins directory?
Steven: you can see the reported crashes for 1.0a1 here: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=&vendor=All&product=Camino10&platform=All&buildid=2005091409&sdate=&stime=&edate=&etime=&sortby=bbid Note that some are known bugs that have been fixed on the trunk (all the JS_DHashTableOperate ones), but I've seen at least one that looks like a JEP issue.
> but I've seen at least one that looks like a JEP issue The ones in libhotspot.dylib (there are four of them) seem likely candidates. Of those, two are due to the incompatibility with Apple's Java Security Update (the ones with the crash in Class_getMethods0()_redirect()). The other two seem related to each other ... but who knows? I really, really, really wish Talkback was able to collect stack traces (at least on Mac OS X) -- without them its incident reports are _much_ less useful.
> I really, really, really wish Talkback was able to collect stack traces (at > least on Mac OS X) -- without them its incident reports are _much_ less > useful. I mean traces for _all_ the threads, as OS X gives you.
talkback should submit crashreporter logs, I wonder if it could be changed to do that. CC me on libhotspot crashes, I can see if they reproduce for us. Firefox should bundle this plugin, that would help our internal testing quite a bit. Users are going to want a 1.4.2 experience instead of a 1.3.1 one, I think the download size/ functionality tradeoff is worth the extra size here.
> CC me on libhotspot crashes, I can see if they reproduce for us. The two "unknowns" are TB9372728 and TB9372670. If you can find a way to reproduce them, please open a bug (either here at bmo or using the JEP's Bugs tracker). If you do it here, be sure to put me on the CC list :-)
Pain that I didn't get the link format right :-( http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=9372728 http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=9372670
> two are due to the incompatibility with Apple's Java Security Update > (the ones with the crash in Class_getMethods0()_redirect()) This is incorrect ... I spaced it out. So, Chris, here are two more to add to the list that you're checking: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=9427363 http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=9407018 Thanks in advance! Java_java_lang_Class_getMethods0_redirect() is actually in MRJPlugin.plugin (in MRJSession.cpp), not in libhotspot.dylib. It's part of a fix for a minor security hole in LiveConnect that I reported to Sun and Apple on 2005-03-07. The Apple "radar" is 4040240. Sun's bug id is 6248410 (which isn't publicly accessible, since this is a security issue, but which Apple no doubt can get access to). My fix appeared in JEP 0.9.2 (released 2005-05-18).
> My fix appeared in JEP 0.9.2 (released 2005-05-18). I'll eventually get this right :-( My fix appeared in JEP JEP 0.9.1 (released 2005-05-09).
For the record, here's what happens to someone experiencing this bug: No Java applets work (loading them appears to do nothing), but the browser continues to function (otherwise) normally. I've attached a log of the error messages you get in the Java Console.
for reference, this would have worked: Incident ID: 9372728 Incident ID: 9372670
*** Bug 309497 has been marked as a duplicate of this bug. ***
'll repeat my question from comment #13 above: Is there any chance that the mechanism used (in Firefox) to install extensions could be used to install JEP updates to the distro's Contents/MacOS/plugins directory?
Maybe Ben can answer that.
We can use the normal software update system which firefox has these days; though, it requiers a version bump anyway, not all that good.
So what do we do here? Is 0.9.4 a viable replacement for 0.9.3 at this point? Does it introduce any new problems? Other concerns, like distributing JEP updates, should get their own bugs.
The update to 0.9.4 (on the trunk and branches) has now waited so long that I'd say you should just wait a bit longer, for 0.9.4+a. I'm working on it as we speak. It fixes a number of fairly significant issues, which it turns out were nearly all old issues (i.e. not introduced by 0.9.4) ... and mostly (though not entirely) workarounds for Apple bugs :-) (One issue that I'm glad I _didn't_ have to deal with is Camino-crashing-on-exit-with-lots-of-applets (comment #12). This seems to have gotten fixed on both the trunk and the branches. It may also have effected Firefox, though less severely.) I hope to release 0.9.4+a in the next couple of days. > Other concerns, like distributing JEP updates, should get their own bugs. I will open a new bug to deal with my question in comment #13 and comment #25, and CC everyone here.
> I will open a new bug to deal with my question in comment #13 and > comment #25, and CC everyone here. Done. It's bug 309636.
Assignee: nobody → joshmoz
Steven: Tuesday is the branch lockdown, and drivers would like a new JEP (0.9.4 or newer) on the branch by then if possible. Since we're getting down to the line, do you plan on having a new version done and stable enough by then or should we land 0.9.4 on Monday?
I should be able to release 0.9.4+a tomorrow, if all goes well. That should be landed on the trunk and both branches. And I think future versions (even future "nightlies") should be landed on the trunk and both branches as soon as they're released. That gives them much greater exposure, and increases the chance that bugs will be found and fixed before an actual "release" (alpha or beta or whatever) takes place.
> I should be able to release 0.9.4+a tomorrow, if all goes well. I'm not going to be able to release 0.9.4+a today -- one of the things I thought I'd fixed turned out not to be. But that issue's now cleared up, and other tests have gone well. I should be able to make tomorrow (Saturday, 9-24). I'll post another note here as soon as it's done.
I've just released version 0.9.4+a of the Java Embedding Plugin. You can download it from http://javaplugin.sourceforge.net/.
> I've just released version 0.9.4+a of the Java Embedding Plugin. You can > download it from http://javaplugin.sourceforge.net/. Please land it on the trunk and the 1.8 and (Camino) 1.0 branches as soon as possible.
> Steven: Tuesday is the branch lockdown, and drivers would like a new JEP > (0.9.4 or newer) on the branch by then if possible. Since we're getting down > to the line, do you plan on having a new version done and stable enough by > then or should we land 0.9.4 on Monday? > I've just released version 0.9.4+a of the Java Embedding Plugin. You can > download it from http://javaplugin.sourceforge.net/. > Please land it on the trunk and the 1.8 and (Camino) 1.0 branches as soon as > possible. Well? :-)
Is it _next_ Monday or Tuesday that's the branch lockdown? I hope so :-) > Upcoming milestones: > > Sept 6: Lockdown for 1.5b1 > Sept 8: Release 1.5b1 > Oct 3: Lockdown for 1.5b2 <------------ > Oct 5: Release 1.5b2 > Oct 26: Lockdown for 1.5RC1 > Oct 28: Release 1.5RC1 (http://developer.mozilla.org/devnews/index.php/2005/08/30/9-days-untill-15-beta/)
JEP 0.9.4+a landed on branch and trunk.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
> JEP 0.9.4+a landed on branch and trunk. Thanks!
You need to log in before you can comment on or make changes to this bug.