JDK-6650374 : speed-trap.com dashboard does not launch due to bug in SetObjectRects heuristics
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-01-15
  • Updated: 2010-09-08
  • Resolved: 2008-02-21
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 b12Fixed
Related Reports
Relates :  
JDK-6627606 - Microsoft LiveMeeting applet does not work
Relates :  
JDK-6670162 - Initially-hidden applets receive (0, 0) for initial width and height
Relates :  
JDK-6639429 - Unable to display applet in new plug-in
Description
The dashboard applet provided by speed-trap.com does not launch with the new Java Plug-In because of overly aggressive heuristics that filter out bogus calls to the COM method SetObjectRects by the Internet Explorer browser. This is a problem that has come up a couple of times before in the development of the new plug-in: see for example 6627606. Unfortunately the reason the old plug-in works appears to be due to subtle race conditions in the old plug-in's startup sequence which have been categorically fixed in the new Java Plug-In. Fundamentally, when SetObjectRects() is called with a zero-sized rectangle, we need to know whether it will ever be called again at some point in the future with a more valid rectangle.

See the Comments section for the test case.
Comments
EVALUATION When instantiating the ActiveX control corresponding to the applet tag, the IE browser makes one or more calls to the COM method SetObjectRects, which sets the bounds of the control, with bogus values. The old Java Plug-In's code to handle this case was extremely difficult to comprehend and was also incorrect for situations such as running applets on a hi-DPI monitor, where IE automatically increases the width and height of images and applets on the web page. In the new plug-in, we have attempted to heuristically detect these invalid calls to SetObjectRects and filter them out, so that we can provide a correct initial width and height when starting the applet. These heuristics have caused some problems in the past, such as 6627606 (Microsoft LiveMeeting applet does not work), in which an applet which deliberately had a zero width and height failed to start. The speed-trap.com dashboard applet defeats even the most recent version of our heuristics. The end result is that at the point SetObjectRects is called, it is not possible to conclusively determine whether we should start the applet or not. It is bad to start some applets with an incorrect initial width and height, because these applets do not handle resizes well. It is worse to fail to launch applets at all because it appeared that the only calls to SetObjectRects were with invalid arguments, when in fact they were supposed to be treated as valid. The heuristics have been changed so that a call to SetObjectRects with a seemingly invalid width and height will not prevent launching of the applet, but only delay it for at most a certain period of time, here defined as 500 ms. This appears to be sufficient to subsume the previous heuristic as well as launch the speed-trap.com applet in a reasonable timeframe. Tested with the speed-trap.com dashboard, as well as the AcuteScroller applet from http://javaboutique.internet.com/AcuteScroller, the VRX studios hotel applets (http://vrxstudios.com/hotel_program), the games at iWon.com (http://games.iwon.com/), the Pogo games, and the regression test for 6627606. Ran each test several times (the Pogo games 30+ times) to ensure that there are no apparent race conditions introduced with this change.
15-01-2008
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6650374.0/ testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6650374/
15-01-2008