Closed Bug 701968 Opened 13 years ago Closed 7 years ago

Java doesn't load since Java SE 6 Update 29 (with plugin version 13.6.0)

Categories

(Camino Graveyard :: Plug-ins, defect)

Product:
Camino Graveyard
Component:
Plug-ins
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: phiw2, Unassigned)

Details

(Whiteboard: rdar://10436669)

Attachments

(3 files)

start patch
3.62 KB, patch
Details | Diff | Splinter Review
1.9.2-branch debugging patch (*not* a fix)
26.69 KB, patch
Details | Diff | Splinter Review
Trunk debugging patch (*not* a fix)
6.31 KB, patch
Details | Diff | Splinter Review 
(placeholder bug)
Reported to Apple as incident 10436669 

Notes:

* test page: http://java.com/en/download/testjava.jsp displays a blank frame instead of a screen showing the java configuration
Whiteboard: rdar://10436669
When I get a chance I'll try to make a logging build to see if they've dropped support for the Carbon event model.

Over time lack of Cocoa event support is going to be increasingly problematic as EOMB supports it, so Carbon event models in plugins that support Cocoa will be largely untested. (Probably also responsible for the reports of click issues in Flash recently.)
It broke in Firefox 3.6.x too; see bug 670655 comment 42 et seq.
If Firefox this problem only happens (with Apple's latest Java update) on Lion -- not with Apple's latest Java update on SnowLeopard.
(In reply to Steven Michaud from comment #3)
> If Firefox this problem only happens (with Apple's latest Java update) on
> Lion -- not with Apple's latest Java update on SnowLeopard.

Right, Java works on S.L with Fx 3.6 because of the JEP.
Installing the JEP anywhere where Camino can use it would allow Java applets to load (or - remove the Jep from Fx 3.6 and you'd see the same issue).
I find JEP rather unstable. Keeps causing Camino to be totally unresponsive while trying to load a second applet.
(In reply to comment #4)

You're absolutely right.  Odd that I should be the one to forget that :-)
(In reply to comment #5)

You should open a new bug.

But note that I no longer really have any time to work on the JEP.  So your bug will need to be easily reproducible by many people for it to be at all likely that I'll try to fix it.
Oh, no, my mistake. It's just one particular site with a bad applet that's causing unresponsiveness.
(In reply to Stuart Morgan from comment #1)
> When I get a chance I'll try to make a logging build to see if they've
> dropped support for the Carbon event model.

Looks like not; false alarm. A custom Chromium build that claims not to support CA and Cocoa will get a working plugin with CG+Carbon. Something else is busted, apparently. Someone should see what NPP_New is returning in Camino or Firefox 3.6, since that might give a clue.
Specifically, someone needs to log or gdb-inspect the value of newResult just after this line:
http://mxr.mozilla.org/mozilla1.9.2/source/modules/plugin/base/src/nsNPAPIPluginInstance.cpp#1374

Assuming we are getting that far, and it's the plugin initialization that fails, it's possible we'll get some information about what the failure is.

Another possibility that occurred to me for what could be going on is that they may be expecting a newer version of the NPAPI function struct, and IIRC there's an error that is more or less designed for that case, so if that's it hopefully we'll see that error.
Okay, that was not at all the right line, but it looks like my second guess was right. NP_GetEntryPoints is returning NPERR_INVALID_FUNCTABLE_ERROR which almost certainly means they expect a higher version of the NPAPI struct.

Our options are:
- Ask Apple to handle this gracefully in the next version
- Leave Java broken
- Backport a newer version of the NPAPI headers (or at least the function table part) to 1.9.2, with NULLs for the things Gecko 1.9.2 doesn't support.
(In reply to Stuart Morgan from comment #11)

> - Ask Apple to handle this gracefully in the next version

Now that we know what's going on, whomever filed the rdar (I think it was Philippe) should probably update it with more information, and/or more of us should file rdars with the updated information.

> - Leave Java broken

This doesn't really strike me as a sustainable option :-p

> - Backport a newer version of the NPAPI headers (or at least the function
> table part) to 1.9.2, with NULLs for the things Gecko 1.9.2 doesn't support.

How much trouble would this be? I don't like the idea of doing this any more than I imagine you do, but if Apple can't or won't be smarter about this on their end, I don't really see any alternative if we want to offer the ability to use Java :(
If you want to add info to the Radar, it would basically be to say that the new version of the Java plugin does not gracefully handle browsers that have older versions of npapi.h, and thus have smaller function table structs, and that ideally instead of failing if the function table is old, this plugin should just make the population of the new elements conditional on the size/version of the struct provided by the browser.
> How much trouble would this be?

I don't know where exactly in the Gecko code some of the function table stuff is handled, but my expectation would be "not that much". Basically we just need a few more functions in the structs, we need to make sure we NULL the new stuff in the browser struct, and we may need to rev the version we pass in. I'd have to double-check all the version changes to make sure there's nothing else required that's implied by reporting a newer NPAPI version, but I don't think there is.
(Assuming that it is easy, and that as I understand it Firefox 3.6 is still supported while the enterprise strategy gets worked out, this is really something that would make a lot more sense to be done in the core code, rather than hacked in to a Camino mini-branch, but I don't even know whose call that is these days.)
I'm assuming this is too late for 2.1, but would a workaround be something we'd want for 2.1.1?

https://wiki.mozilla.org/Modules/All#Plugins still says Josh and jst, so I'll cc them here and ask.
Flags: camino2.1.1?
Whiteboard: rdar://10436669 → rdar://10436669, theoretical workaround in comment 14
Executive summary for those just CC'd: Apple's Java Plugin2 no longer loads in Firefox 3.6 or Camino 2.x, because the plugin is failing due to the NPAPI function table struct being too old/short. How plausible is a backport of the extended tables, with the appropriate NULLing of all the unsupported functions, to 1.9.2 (assuming that fixes Java, which I very strongly suspect it will given that I've verified that it still support CG+Carbon).
I've updated my Radar bug report with the URL to this bug and the summary of the findings based on comment 13.
> How plausible is a backport of the extended tables, with the
> appropriate NULLing of all the unsupported functions, to 1.9.2
> (assuming that fixes Java, which I very strongly suspect it will
> given that I've verified that it still support CG+Carbon).

I'm working on this, and should have an answer soon (later today or
early next week).
My real question, which I lost in the summarizing, is whether there's any chance such a change would get landed on 1.9.2 (so that we don't have to minibranch it for every 2.1.x release).
I can't say until I know more.

But if I can find a simple solution, I'll strongly advocate landing it in the 1.9.2 branch.
Ok, I got this working. I need to do testing to ensure it is stable and complete.
Attached patch start patch — — Splinter Review 
Here is a patch that will successfully load the java test page. We crash once we leave it. I won't be able to continue working on this until Monday so feel free to improve upon it.
This appears to be an Apple bug, and I doubt there's anything we can
do about it.

I've confirmed that Pete Collins' patch from comment #23 behaves as he
describes it.  It "works" until the first Java plugin instance is
destroyed.  Then the Java plugin aborts the browser process.

Note that this isn't (technically) a crash.  Instead the Java plugin
calls CFRelease on a NULL pointer, which causes CFRelease to kill the
current process.

Apple's new Java plugin does an error return from NP_Initialize()
unless browserFuncs->size is '80' (what it is in current trunk code,
and what Pete's patch and my patches make it).  But it doesn't pay any
attention to the version number passed in browserFuncs->version -- it
makes no difference whether this is set to '22' (as it is in current
1.9.2-branch code) or '27' (as it is in current trunk code).

You'll see from my debugging patches that, when running in FF 3.6.X,
the current Java plugin sets the drawing model to '1' (i.e. to
NPDrawingModelCoreGraphics).  On the trunk (and presumably since FF
4.0) it sets the drawing model to NPDrawingModelCoreAnimation (and the
event model to NPEventModelCocoa).

My best guess is that the current Java plugin's support for
NPDrawingModelCoreGraphics (and NPEventModelCarbon) is nominal -- that
Apple never really tested it, and so didn't realize that it's badly
broken.  Anyone know of another browser (even an older version of a
current browser) that would likely force Apple's current Java plugin
to use NPDrawingModelCoreGraphics and NPEventModelCarbon?  If one can
be found, it'd be interesting to test on it.
Whiteboard: rdar://10436669, theoretical workaround in comment 14 → rdar://10436669
> Anyone know of another browser (even an older version of a current
> browser) that would likely force Apple's current Java plugin to use
> NPDrawingModelCoreGraphics and NPEventModelCarbon?  If one can be
> found, it'd be interesting to test on it.

Interestingly, if you hack current trunk code to tell plugins that the
browser doesn't support the Core Animation drawing mode, you get the
same crashes as with Pete's patch (and my 1.9.2-branch debugging
patch).

I forgot to mention earlier that changing the 1.9.2-branch's
user-agent string to match current trunk code does change the Java
plugin's behavior.  But the Java plugin still chooses the Core
Graphics drawing model (and, by default, the Carbon event model), and
it still kills the browser process when a plugin instance is deleted.
(In reply to Steven Michaud from comment #24)

> Anyone know of another browser (even an older version of a
> current browser) that would likely force Apple's current Java plugin
> to use NPDrawingModelCoreGraphics and NPEventModelCarbon?  If one can
> be found, it'd be interesting to test on it.

Pretty sure Stuart made a custom Chromium build (for comment 17) and it worked fine, but I'm not sure how extensive his testing was.
Flags: camino2.1.2?
Flags: camino2.1.1?
Flags: camino2.1.1-
Didn't really follow all of above, but I cannot see any thumbnail photos on my Yahoo Homepage using Firefox  on my Mac SNow Leopard x 10.6.8  I gather it may have to do with this Java update.  The Java says it is 13.6.0  Nov 1, 2011.  I have no problem accessing with Safari - everything looks right and it says it is using Java 1.6.0_29.  My brother can access my homepage through Yahoo on his computer same as mine with firefox.  I thought all our software was same versions.
Can anyone tell me what to do .
additin to above.  I think this may have began after upgrading firefox from a version of 3.  now it is 11.
This bug is for Camino, not Firefox, so you are in the wrong place.
I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: