Community
Participate
Working Groups
Created attachment 272371 [details] Sirius project to reproduce the problem The bug is reproduced on windows 7 only (not on windows 10). Sirius 5.1.0 EEF 2.0.1 In a Sirius properties view, when a text widget is "active" (cursor inside the text box - after a modification of it's value), the selection of a "select" widget right after the text box makes Eclipse flicker and freeze. Then, Eclipse should be killed to exit. Note 1 : if the user click outside the textbox after the edition or tap "Enter" before clicking on the "select" widget everything works as expected. Note 2 : if we debug the operation with a step in the EEFSelectLifecycleManager$EEFSelectLabelProvider getText(Object) method and go step by step on the first rounds, Eclipse do not freeze. The attached file contains a sample family project modified to add a properties view for the "Person" class with a text widget for "name" editing and a "child" select widget to reproduce the bug.
I can't reproduce under Linux, but it's probably related to the events sent by the SWT widgets. We've already hit some system-specific corner cases where the events we expect are not sent, or not in the same way/same order.
Created attachment 272404 [details] Sample project to try to reproduce the issue I can't reproduce using this simple sample project, even under Windows 7.
Created attachment 272405 [details] Video showing the failure to reproduce As can be seen on the video, there is indeed a graphical "glitch" when switching from the text widget to the combo, but no freeze, deadlock or crash.
Reproduced under Windows 7 (inside a VM), using the first attached example. I'll try to reproduce using a simpler VSM. What seems to happen: * the combo opens; * "at the same time" (it's in the same thread, but probably a queued SWT event which gets executed after the combo is opened), we lose the focus in the text field, which triggers the execution of the associated edition behavior (in this case, "Set Value" on the name of the person); * this model change triggers a refresh of the widgets, including the combo. * for the combo, we recompute the candidates and call setInput() with the result; * and here is the issue: it seems Win 7 (at least) does not like at all that we change the input while the combo is opened. It looks like even though the user has not selected anything, calling setInput() calls back on the combo's selection listener, which starts an infinite loop of events.
Moved to EEF, as the issue (and fix) are purely on this side.
New Gerrit change created: https://git.eclipse.org/r/116091
Gerrit change https://git.eclipse.org/r/116091 was merged to [master]. Commit: http://git.eclipse.org/c/eef/org.eclipse.eef.git/commit/?id=78d12316b8f118cd30e68973dc5ae641430dea79
Fixed by 78d12316b8f118cd30e68973dc5ae641430dea79.
Validated with Sirius5.1.1rc5
New Gerrit change created: https://git.eclipse.org/r/116622
