As of FireFox 7b1 through 8b1, attempts to retrieve values from a Java applet via JavaScript (either by invoking a method or public variable) result in an undefined value. In the case of method invocation, the method is still correctly invoked, it simply retrieves an undefined value. The attached HTML/Java demonstrates the issue. On FireFox 6.0.1 and below, clicking both "Test" buttons will result in an alert appearing containing "100". On FireFox 7.0b1 and above, both buttons will result in an alert appearing containing "undefined".

Live proof of concept for your convenience: http://173.255.234.178/ff7bug/

Confirmed on Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111005 Firefox/10.0a1 ID:20111005030932

Further testing indicates that the problem is reproducible on Windows XP and Mac OS 10.6.7, and occurs regardless of whether the applet is embedded via an <applet>, <embed>, or <object> tag.

Last good nightly: 2011-06-20 First bad nightly: 2011-06-21 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=058a584ea7d3&tochan ge=a285146675dc

Matti, would you be willing to bisect on TM nightlies too?

good 13.06.2011 Built from http://hg.mozilla.org/tracemonkey/rev/e39bcd6cba32 bad 14.06.2011 Built from http://hg.mozilla.org/tracemonkey/rev/3acacde59381

So this regressed on TM a full week before regressing on m-c? I'm going to assume that the m-c merge in that TM pushlog is not relevant, then. Jeff, could your changes have caused this issue? Josh, do you have time to bisect this by any chance?

Sorry, I'm too busy with schoolwork to do more than post convenient pushlog links.

I confirmed both regression ranges again to be sure that I didn't make a mistake. I had a build environment several times in the last few years but i have currently problems with the build setup and can't do a bisect. A special tryserver for bisecting and with access for people like me would be nice.

OK, I'll try to do the bisect here. Note that in a trunk debug build as soon as I click the "test 1" button I get: Assertion failure: vp->isPrimitive(), at ../../../mozilla/js/src/jsobj.h:1469 which is of course fatal. Likely related.

The first bad revision is: changeset: 70734:d2250fc608cc user: Jeff Walden <jwalden@mit.edu> date: Fri Apr 01 15:24:21 2011 -0700 summary: Bug 646129 - [[DefaultValue]] on Date objects is wrong when called with no hint. r=luke I double-checked that a few times, too.

Looks like the assert in comment 11 wasn't introduced in the changeset involved, though. No idea when that started happening....

I added the assert a bit later, blame would point it out pretty easily. Too bad I didn't have the assert from the start, it'd have made obvious a few others bugs too. :-( This got fixed in bug 679509. I'm looking at adding the fix to branches, too, so it should be fixed in Firefox 8, and maybe potentially if there's another 7.0.x in that as well. (I don't fully understand the calculus we use to take fixes there, or to decide when to make a dot release, so can't say anything with certainty about 7.)