Community
Participate
Working Groups
Version: CVS HEAD In some situations, modal dialogs (including progress dialogs) will leave the application in a _hung_ state upon close. The result is that after the dialog disappears, the div that shows the lightbox effect remains on top, effectively blocking any interaction with the application. I have experienced this in two different applications, and am trying to produce a sample project.
Austin, any progress on a snippet to reproduce it?
(In reply to comment #1) > Austin, any progress on a snippet to reproduce it? I have not been able to produce an isolated sample project. However, I have at least some idea of what is related to the problem. I found that if I comment out the content of the *block* and *release* functions in ClientDocument.js the problem seems to disappear in my applications. That is all I have found up to now. I hope it is in some way helpful.
Created attachment 211104 [details] simple project with RAP mail demo hi, this bug is reproducible with attached RAP mail app demo. run the RAP demo mail app attached, and click the "Open Message" action. in MessagePopupAction class, i'm using UIJob here is the sample code.. public void run() { final UIJob job = new UIJob("") { @Override public IStatus runInUIThread(final IProgressMonitor monitor) { MessageDialog.openInformation(window.getShell(), "Open", "Open Message Dialog!"); return Status.OK_STATUS; } }; job.setUser(true); job.schedule(); } when using UIJob, the dialog exit behavior is frozen. regards, sudesh bulathsinhala
Thanks Sudesh!
Thanks, Sudesh. I can reproduce the issue with your snippet.
The issue is interesting: actually we have two *modal* shells created one after another. The first one is a "progress monitor" shell, the second one is the MessageDialog opened in the UIJob#runInUIThread. When you press on the MessageDialog OK button it is successfully closed, but the "progress monitor" shell stays *below* the main shell in a hung state and keep the blocking overlay opened.
To be precise the first shell is a ProgressMonitorFocusJobDialog.
First, the bug does not exists with RAP 1.4. It is a regression from the protocol migration. The problem is in the ShellAdapter#factory where the Shell is opened (call result.show()) when Shell is created. This is completely wrong. You could create a Shell without open it (make it active and visible). A fast and dirty hack in ShellAdapter to open the shell when "active" property is set to true solves the problem. Looking for a clean solution.
Created attachment 211181 [details] Proposed patch This patch uses the old (from 1.4) method adopted to the protocol to render the shell opening. I've created a property "opened" instead of method "open" as based on the comments in the LCA order matters: opened, active, mode. Austin, could you give it a try with your applications? Tim, do you have any concerns?
I dont quite get why we need "opend" and "visibility" - both do the same on the client, don't they, only that open also calls centerToBrowser before.
(In reply to comment #10) > I dont quite get why we need "opend" and "visibility" - both do the same on the > client, don't they, only that open also calls centerToBrowser before. "visibility" is a control property and it is set after the other Shell properties. Based on the comments in the old/current LCA "open" *must* be called before "mode" and "bounds". But if this is not obligatory anymore (we have to check all old related bugs) we could try to stay only with "visibility" property.
I have found another case that can be used to reproduce this issue. I used the following code in an eclipse.ui command handler, but it could just as easily be placed on any user action such as a button click. Shell sh = HandlerUtil.getActiveShellChecked(event); MessageDialog md = new MessageDialog(sh, "", null, "message", MessageDialog.ERROR, new String[] {"OK"}, 0) { @Override protected Control createDialogArea(Composite parent) { throw new IllegalStateException("dialog failed creation"); } }; int result = md.open(); The dialog goes through the process of opening, which notifies the client and displays the lightbox, but the dialog's construction was halted via runtime exception and the lightbox never went away. I suspect something on the client needs a construct similar to try/finally to ensure it is properly cleaned up.
Paul, I've modified the Controls Demo DialogTab with your snippet, but what I get is the "HTTP ERROR: 500" with "java.lang.IllegalStateException: dialog failed creation" as expected. Could you provide a complete self-running snippet to reproduce it?
(In reply to comment #13) Hello Ivan, I have tested your patch with Paul's use-case and it fixes the problem. Good work!
Fixed in CVS HEAD without introducing new property in the protocol. Overrided "visibility" property instead as Tim suggested. Changes are in CVS HEAD.
*** Bug 373884 has been marked as a duplicate of this bug. ***
