JDK-6536861 : File Dialog goes behind the IE after clicking some where on the html content but not on the applet
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_vista
  • CPU: x86
  • Submitted: 2007-03-21
  • Updated: 2011-02-08
  • Resolved: 2011-02-08
Description
I have a applet which has a single button, clicking on the button invokes the file dialog. Which is a modal dialog. Clicking on the applet ,makes the filedialog to flicker which is a correct behaviour. If i click on the title & border of the browser the behavoiur can be seen (filedialog flickering). But if i click some where out side the applet , but with in the html page content, then the file dialog goes behind the html page.  I have to  click twice to get the filedialog above the applet.  This may make the user to get confuse , he/she may try to click on the applet button which goes not invoke the file dialog. He/she may press Alt + F4 to close the browser . this action closes the browser it self. which is incorrect. 
It is reproducable in vista & windows xp professional IE 7.0 , but not reproduced in FireFox or Mozilla in win xp.

Step to reproduce:
------------------
1) Load the applet in IE 7.0 in vista ultimate.
2) click on the "Click Me" button. Observe that you will see  a file Dialog.
3) Click on the applet the file dialog flickers.
4) Click on the title of  the browser & the close button of the browser, the file dialog flickers.
5) Click some where on the html page , but not on the applet. Observe that File dialog goes behind the browser. If you see the same then the bug is reproduced.
6) Click on the applet once. Observe that file dialog does not come on top of the applet.
7) Click on the applet once again . Observe that file dialog goest on top of the applet. Actually the file dialog should come on to of the applet for the first click .
8) Repeat step (5).
9) Press space & Alt button so that browser system menu is seen. Select ALT + F4 ( to close the browser). If the browser closes & file dialog disappears. then the bug is reproduced.
Comments
EVALUATION That is not a bug. IE can contains several tabs. In accodance with IE security model all tabs are independant. It means that the tab in focus could not prevent an access to others. The described CR request contradict IE security policy and cannot be implemented without punitive MS reaction.
08-02-2011
EVALUATION As per previous comments there's a solution to fix the problem: install the modal hook for the additional browser threads. Dispatching the bug to java_plugin as this is browser specifics and it's better to set the hook in plugin code. Btw, there is a very similar issue with the modal hooks fixed in jdk7 - http://monaco.sfbay/detail.jsf?cr=6883952 Hopefully, the change for 6883952 also fixes this bug (6536861) or at least makes the situation better.
23-11-2010
EVALUATION > http://forums.java.net/jive/thread.jspa?messageID=484001 > This looks quite a similar issue. If not, please file a separate CR to track the issue reported on the forum. Yes, the same issue exists for the print dialogs.
23-11-2010
EVALUATION Users report that sometimes the PrintDialog can be displayed behind the browser window when showing initially. See: http://forums.java.net/jive/thread.jspa?messageID=484001 This looks quite a similar issue. If not, please file a separate CR to track the issue reported on the forum.
30-09-2010
EVALUATION Current AWT implementation contains some code which is related to browser modality. Namely, AWT sets a hook procedure on the browser thread (the hook is responsible for activation of modal dialog in case of user tries to activate the browser). The hooked thread is thread which creates browser's top-level window and other threads (if any exist) are non-hooked. So if user clicks on any part of the browser which is created on any non-hooked thread (e.g. if user clicks on non-applet area of the tab), the browser appears above the modal dialog.
03-10-2007
EVALUATION The current implementation of modality - events part - in AWT is the following: all the mouse events are filtered at the Java level, all the focus events including window activation are filtered at the native level, so keyboard events are not handled at Java level at all. However, there are some places when we deal with mouse events in the native code. One of these places is responsible for bringing the blocking dialog to the top when any of its blocked windows is clicked. However, this action is currently performed only if any Java window is clicked, not the browser window. That's why it is raised above the modal dialog.
21-03-2007