JDK-6676489 : Java/JavaScript string handling changes break ESPRE Solutions videos in IE with new plug-in
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2008-03-18
  • Updated: 2010-09-08
  • Resolved: 2008-06-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b21Fixed
Related Reports
Relates :  
JDK-6720093 - new-plugin doesnt show the streaming vedeo from http://www.espresolutions.com/demo_stream.php
Relates :  
JDK-6678349 - Regression: speed-trap.com dashboard doesn't load
Relates :  
JDK-6632668 - FF3: Calls to java APIs directly is not working under all scenarios
Relates :  
JDK-6678350 - Regression in handling of OBJECT tag and name parameter in IE
Description
The fighter pilot streaming video demo (for example) linked from http://www.espresolutions.com/demo_stream.php fails to load in the new Java Plug-In, apparently because a LiveConnect call fails just as it's about to display the video. We need to determine exactly what is going wrong. This content works in the old Java Plug-In. It also works to some degree in Firefox 3 though the video shows up in the wrong place on the web page.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6676489.0
21-03-2008
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.
21-03-2008
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.
20-03-2008
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.
20-03-2008