JDK-6582571 : Webcam applets failure after updating JRE to 6u02/6u03/6u10 works with 1.4.2_14
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0,6,6u2,6u3,6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2007-07-19
  • Updated: 2010-11-03
  • Resolved: 2008-06-18
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 JDK 7
6u10 b21Fixed 7Fixed
Related Reports
Relates :  
JDK-6729677 - popcap- applet games fail to load
Description
FULL PRODUCT VERSION :
Version 1.6.0 (build 1.6.0_02-b06)

FULL OS VERSION :
Operating system Xp sp2 All updates completed to date
ATI RADEON X1600

BROWSER VERSION:
Internet Explorer IE7

Problem Details:

Webcam hosting and Webcam Network sites using Java applets fails to work properly after updating to latest JRE release Version 1.6.0 (build 1.6.0_02-b06).

Actual Behavior:
Launch a web cam applet site, for example:
http://www.paris-live.com/paris_webcam/eiffel_tower_cam4.htm
Note: Ensure Java Sun (JRE) is enabled for Internet Explorer under Advanced settings. Also Plug-in is listed enabled in IE Add-ons

Applet display the initial image and remaining steadfast/stuck thereafter without any further movement. This is a general behavior among common webcam applets and across different browser(s) including Firefox/Mozilla etc.  Also note that all the sites I tried to run are listed as trusted/safe, so that they loads without permission and any active x extras can be installed. Normal Java applet loads correctly.

This seems to be a regression since testing with 1.4.2_14, applets performed fine.

Some example web sites (applets) exhibiting problem:

1. http://www.paris-live.com/paris_webcam/eiffel_tower_cam4.htm
2. http://www.standrews.com/webcams/oldcourse.htm 
Note: for some reason the Edinburgh City Centre does work
3 Many cams at http://www.networkwebcams.co.uk/
Few more applets with failures reported after updating to 6u03:
4. http://www.highcountrywebcams.com/webcameras_sprucepine.htm
5. http://www.highcountrywebcams.com/webcameras_BeechSlopeside.htm
6. http://www.highcountrywebcams.com/webcameras_appalachian.htm

Tested with java version "1.6.0_10-ea" release:
Applets still failed to work.
This is confirmed to fail with latest available JRE version at java.com that is 6u03 and latest available Java Kernel release 6u10ea at java.net


Expected Behavior: 
Applets should be able to provide live feed/pictures continually.
Comments
EVALUATION Basically, there are two issues: 1.) Since java 1.6, the image source of an image created by plugin was changed to a byte array from a url. When an image is flushed and reconstructed, it is constructed from the in-memory byte array instead of opening the url and reading from the web. 2). Java plugin cache checks and downloads resources from web only once per browser session. This prevents updated image files on webserver being checked and downloaded. The fix is to change url as the image source and flush plugin cache entry when image.flush() is called. This works for the classic 1.6 plugin and the new out-of-process plugin (avail in 6u10). The new plugin supports to run applets in earlier java vms (for example, 1.5 and 1.4.2). There is one scenario that the problem may still happen which is when applets are run in the new plugin and 1.4.2 jvm. Note this is not common user case. And none of the current webcam applets fall into this scenario. To workaround it, webmasters of those applets need configure their web servers to send "No-Cache" or "Expires" directives in HTTP header to tell java plugin not to cache those files.
04-03-2008
EVALUATION The security exception in the new OOPP seems to be caused by a applet class (View.class) on the desktop. It looks that plugin loads the View.class from the Destktop and the applet ProtecionDomain is the Desktop which has no permission connectiong the http server. After I deleted the View.class from the Desktop, it worked fine connecting to the server.
05-02-2008
EVALUATION The webcam applet (use http://www.highcountrywebcams.com/webcameras_BannerElk.htm as an example) depends on Image.flush() to update images from the server. The image on the server has the same file name and supposed to be updated by the webcam frequently. Plugin implementation of AppletContext.getImage() cache images in a hash map. If Image.flush() does not nullify the cached image, the cached version will always be painted. In the new OOPP plugin, there appears to be a separate security issue. The security manager does not permit to resove host name. In the old plugin, it has no this issue. Exception in OOPP access: access denied (java.net.SocketPermission www.highcountrywebcams.com resolve) basic: Removed progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@13bad12 Exception in thread "thread applet-View.class-1" java.security.AccessControlException: access denied (java.net.SocketPermission www.highcountrywebcams.com resolve) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkConnect(Unknown Source) at sun.plugin2.applet.Applet2Manager$AppletContextImpl.getImage(UnknownSource) at java.applet.Applet.getImage(Unknown Source) at java.applet.Applet.getImage(Unknown Source) at View.refreshImage(View.java:105) at View.init(View.java:81) at sun.plugin2.applet.Applet2Manager$AppletExecutionRunnable.run(UnknownSource) at java.lang.Thread.run(Unknown Source) Domain permissions in old plugin: (java.net.SocketPermission www.highcountrywebcams.com connect,accept,resolve)
05-02-2008