JDK-6621874 : Modal dialog blocking of browser imprecise with introduction of class loader cache
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u5
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: windows
  • CPU: generic
  • Submitted: 2007-10-26
  • Updated: 2015-01-21
  • Resolved: 2015-01-20
Related Reports
Relates :  
JDK-6618920 - Plugin2 : Add classloader caching support to new Plug-in
Description
With the introduction of the class loader cache in 6618920, the implementation of modal dialogs' blocking of the web browser has become imprecise in some situations. Consider the case where the simple ModalityTest is loaded in two separate browser windows. Since they now share the same class loader and AppContext, it is essentially random which Applet2Manager instance will be picked up during modalityPushed() and therefore random which browser-side plugin instance, and browser window, will be blocked.

Probably the only technically feasible solution would be to block all browser windows for all plugin instances sharing the same AppContext. It's unclear whether this would be a good solution from the user experience standpoint.
Comments
EVALUATION This isn't a showstopper for 6u10; many issues with modal dialog handling exist in the classic Java Plug-In, and the new Java Plug-In's behavior is better than the classic Java Plug-In. Decommitting from 6u10 and recommitting to 6u12.
15-05-2008