Community
Participate
Working Groups
Build Identifier: 20100218-1602 When I do Display.syncExec, there is sometimes no UI update at all. I provide test project to reproduce the error. In our terminal project there is complex UI change in Display.syncExec runnable code. When we upgraded to RAP 1.3 the UI is not updated until user click some action (resize window, etc.). In RAP 1.2 there is no such problems. Reproducible: Always Steps to Reproduce: 1. Run the test project 2. When you click on the button "OK" or "Buggy", there should appear new editor with two labels. 3. When you click Buggy several times, there will be only one label visible. 4. When you click Buggy any times, there will be always both labels visible. 5.
Created attachment 170169 [details] Test project to reproduce bug
I don't think that your problem is related to Display#syncExec(). If you do not use syncExec, but execute the code that creates the labels directly, the problem remains. I don't see a reason to use syncExec in these Actions anyway, as the Action's run method will be executed on the UI thread. I think that you have a layout issue in your editor. Adding a parent.layout() call after creating the labels will probably help. Closing as INVALID, please reopen if I missed the point.
Well maybe this test project is not the best one to simulate that. I have removed the separate thread because it behaves the same, so to make things easier... Differences between this example and our project. Display.syncExec is executed from different thread. This thread update terminal screen with UI widgets. They are not updated until someone click on the menu/editor/view. In the RAP version 1.2 there is no such problems, it started to behave strange after I update RAP to version 1.3. I tried to call composite.layout() after UI changes but with no success. The point is why there is no problem when the text alternate ? I have also created another issue, that may be connected together. When there is UI change by Display.syncExe, TextSizeDetermination is not called, so all labels has wrong width. This is common for RAP 1.2 and 1.3.
Could you please provide a simple snippet (just a class that implements IEntryPoint, not an entire RCP project) that reproduces your problem with syncExec?
Created attachment 170762 [details] our class that implements IEntryPoint
How does your second example demonstrate your problem? There's no syncExec in it.
I have tried it once more with the latest RAP 1.3 update. It works fine in FF 3.6.3, but it does not in IE8, opera 10.5.3, chrome 5.0.375.55.
(In reply to comment #6) > How does your second example demonstrate your problem? There's no syncExec in > it. You mean whole test in one class. Well I can try, but not sure if possible.
(In reply to comment #8) > (In reply to comment #6) > > How does your second example demonstrate your problem? There's no syncExec in > > it. > > You mean whole test in one class. Well I can try, but not sure if possible. After installing firebug for IE, I have found out the source of the bug. I have key listener attached to the Field/Combo and just after I type something, the listening conection GET rap?nocache=1275570904348&custom_service_handler=org.eclipse.rwt.internal.lifecycle.UICallBackServiceHandler 0 Unknown 6703ms crashed. I will try to make some demo to simulate. It may be something in SyncKeyEventUtil since FF uses AsyncKeyEventUtil. I tried to force AsyncKeyEventUtil.js for IE and it refreshes correctly, but with other bugs.
Created attachment 170962 [details] Test class to reproduce problem Just run, there is shell with label a text. The label gets updated each second. The Text has key listener attached, just type any character into it and the UICallBack will crash and disable any further update.
Added straightforward example to simulate this bug.
Hi Ralf, I am not sure if this is related behavior to this bug, but in our experience, a RAP client application can lockup when a UICallback is running and Display.syncExec is called on a display that has no client attached anymore. The problem case for us was when we had listeners that were orphaned /not unregistered and notified after their corresponding client was closed. The syncExec would basically block and the notification of the other listeners would never happen. I will try to get a sample project together.
Created attachment 172058 [details] Sample project illustrating problem in comment 12 This project illustrates the problem described in comment 12. Steps to reproduce: 1. Run the app, and go to File->Fire Test Notification. Observe the ui popup. 2. Now create multiple client sessions by closing the browser (very important step), and reopening a couple of times (Don't forget to copy the URL). This registers several sample listeners in the plugin activator for testing. 2. Open the browser one more time and go to File->Fire Test Notification in the application. 3. Observe that the application hangs. To confirm on a code level set a break point in ApplicationActionBarAdvisor:50 and step into the runTest method. Observe that the call to syncExec() in ApplicationWorkbenchAdvisor:48 blocks the calling thread due to the orphaned display, thus preventing the app from continuing. If you comment out the UICallback in ApplicationWorkbenchAdvisor you will notice that the same test will result in similar behavior. I would be happy to open this in another bug, but it seems strangely related.
(In reply to comment #13) > Created an attachment (id=172058) > Sample project illustrating problem in comment 12 > > This project illustrates the problem described in comment 12. > > Steps to reproduce: > > 1. Run the app, and go to File->Fire Test Notification. Observe the ui popup. > > 2. Now create multiple client sessions by closing the browser (very important > step), and reopening a couple of times (Don't forget to copy the URL). This > registers several sample listeners in the plugin activator for testing. > > 2. Open the browser one more time and go to File->Fire Test Notification in the > application. > > 3. Observe that the application hangs. To confirm on a code level set a break > point in ApplicationActionBarAdvisor:50 and step into the runTest method. > Observe that the call to syncExec() in ApplicationWorkbenchAdvisor:48 blocks the > calling thread due to the orphaned display, thus preventing the app from > continuing. > > If you comment out the UICallback in ApplicationWorkbenchAdvisor you will notice > that the same test will result in similar behavior. > > I would be happy to open this in another bug, but it seems strangely related. Your observation isn't a bug in the closest sense - unless the blocking syncExec isn't released when the session times out. When closing the browser window, the server isn't notified. Bug 284273 requests to improve this situation, however, due to the way some browsers behave there isn't a reliable way to detect when a browser window is closed *and* send a request to inform the server about this fact. With this in mind, the syncExec call is 'just' blocked and waits for the next call to readAndDispatch. Naturally, this call will actually never happen as the UI (i.e. browser) is already closed. The synchExec will be released on session timeout. BTW is there a real reason why you are using syncExec instead of asyncExec?
With the attached code (TestBug614640), I cannot reproduce any problem. The text changes every second as expected.
(In reply to comment #15) > With the attached code (TestBug614640), I cannot reproduce any problem. The > text changes every second as expected. May I ask whom source have you tested ? This one ? https://bugs.eclipse.org/bugs/attachment.cgi?id=170962 I believe that comments from Austin Riddle is completely out of topic and he should had open his own issue. I'm quite desperate on this issue, it is very straight forward to reproduce. and seems like nobody cares to confirm or reject.
(In reply to comment #16) > (In reply to comment #15) > > With the attached code (TestBug614640), I cannot reproduce any problem. The > [ ... ] > > May I ask whom source have you tested ? > This one ? https://bugs.eclipse.org/bugs/attachment.cgi?id=170962 > As stated in comment #15, I used "TestBug614640" (3rd attachment) to reproduce. Browser was FF 3.6
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > With the attached code (TestBug614640), I cannot reproduce any problem. The > > [ ... ] > > > > May I ask whom source have you tested ? > > This one ? https://bugs.eclipse.org/bugs/attachment.cgi?id=170962 > > > As stated in comment #15, I used "TestBug614640" (3rd attachment) to reproduce. > Browser was FF 3.6 Yes, I have stated that this bug in valid only for SyncKeyEvent handler, so IE, possibly chrome, opera, etc.. FF uses AsyncKeyEvent handler, so there is no bug under FF, please use IE.
(In reply to comment #18) > [ ... ] > Yes, I have stated that this bug in valid only for SyncKeyEvent handler, so IE, > possibly chrome, opera, etc.. FF uses AsyncKeyEvent handler, so there is no bug > under FF, please use IE. OK, I also tested with IE 8 and Chrome (latest). Same here - everything works as expected. It's not that noone cares (see the various replies), it is just that it is *not* straigt forward as we are not able to reproduce.
Please reopen. I just noticed this bug and I wanted to give it a try to reproduce it, so that lukas gets satisfied :-) And, I DO have the same issue using CVS Head from 20.05.2010. Modified the snippet to use gridlayout for better look, but the rest of the code is the same :-) As soon as I enter a character into the text, then the label does not get updated anymore. Same happens if I use the Jobs API instead of a java thread. If you enter the next character, the the ui gets update again once.
I can now reproduce the problem. I opened bug 317616 to capture the issue.
