SUGGESTED FIX

http://sa.sfbay.sun.com/projects/deployment_data/6u10/6676489.0
                                     

EVALUATION

There has been a longstanding discrepancy between the IE and Firefox
browsers in how Java String values are returned to JavaScript,
specifically as the return values from method calls from JavaScript to
Java. The IE browser would perform an immediate conversion from the
Java String to a native string in the JavaScript engine. The Firefox
browser would "box" the string, keeping it in the form of a
java.lang.String, and when future calls were made against the string,
they would be JavaScript-to-Java calls. The only time the Firefox
browser would convert a Java String to a JavaScript string was upon a
call to the Java method Object.toString(). (The toString() method has
special semantics in most JavaScript engines.)

Early in the development of the new Java Plug-In it followed the IE
semantics for String handling. Later, LiveConnect test cases from
Mozilla were discovered that motivated changing the behavior to the
Firefox semantics under 6632668. At this point, it has been discovered
that the Firefox semantics break the real-world applets of ESPRE
Solutions.

We have carefully considered the alternatives and believe that the
correct thing to do is to revert the new plug-in to the IE semantics
across all browsers. This is more efficient, has more clearly
explainable semantics to developers, and has a motivating real-world
use case. The only motivation for the Firefox string handling
semantics was an obsolete LiveConnect test case which has been updated
for this bug fix.

This fix has been thoroughly tested with both existing test cases and
real-world applets:

  - Automated LiveConnect tests (slightly modified to work with the
    new semantics)
  - ESPRE Live video applet (not fully working yet, though)
  - Pogo applets
  - iWon.com games (had to temporarily increase some timeouts, because
    the Flash advertisements on the page were consuming 100% of the
    CPU and preventing the Java Plug-In from operating properly --
    these hacks are not in this webrev and will not be checked in)
  - VRX Studios hotel applets
  - upnext.com
  - speed-trap.com dashboard (currently broken, being fixed under
    6678349)
  - NeuroKernel's NeuroDNA
  - NASA World Wind Java applet

No specific regression test case, as it has proven very difficult to
distill the 15,000 lines of JavaScript in the ESPRE applets' web pages
into a concrete test case. This functionality is covered by existing
test cases, some of which may break, but we will simply have to revise
these test cases.
                                     

EVALUATION

Initial investigation indicates that the problem may be related to calls to String.split() and handling of the resulting array. It isn't clear whether the JavaScript used by this app expects to be operating on Java Strings or JavaScript strings at various points. Need to write a targeted test case trying to mimic this behavior and see how the old and new plug-ins both for IE and Firefox work.
                                     

EVALUATION

The root cause of the JavaScript error that breaks the 15,000 lines (!) of JavaScript code associated with this applet is a change we made in the semantics of String values returned from the Java Plug-In to the web browser in the new plug-in. Previously, Java Strings returned to the JavaScript interpreter in IE would be converted to JavaScript Strings. Now, unless you call Object.toString() explicitly, Java Strings are returned as Java String objects to the JavaScript interpreter. This difference in semantics breaks this app, even though Java Strings and JavaScript strings behave similarly.

We have gone through a couple of iterations on the semantics in this area during the development of the new Java Plug-In. Initially, Java String return values were always converted to JavaScript Strings. This was then changed in 6632668 to maintain compatibility with existing LiveConnect test cases from Mozilla. The boxing of Strings was mainly motivated by these test cases. However, it seems that this may have been a bad idea. These LiveConnect test cases are a relatively esoteric use case, but this customer's code is an example of existing Java/JavaScript code that used to work in IE and that doesn't work with this semantic change.

Attaining uniform behavior across browsers is paramount in the initial release of the new Java Plug-In. We will probably change the semantics so that only an explicit call to "new java.lang.String()" from the JavaScript engine will actually fabricate a new Java String, and that all Java String return values will be implicitly converted into JavaScript Strings. It is possible that this may break old content designed specifically for the Mozilla LiveConnect semantics, but we believe this will affect only a small minority of users, if any.

The ESPRE demos such as their fighter pilot video still don't work yet in the new plug-in in IE after this fix. Continuing to investigate why; this may be due to changes in the initialization sequence between the old and the new plug-ins and what size the applet had at the time init() or start() was called.