Community
Participate
Working Groups
Subset of issues with bug 329657. Open Xtext based editor. Run a build job that works longer. Try to type inside the Xtext editor - UI will lock immediately and will stay locked / frozen as long as workspace is locked by the build job. Ideally there should be shown a "progress" dialog with the possibility to cancel current task (it is ValidateStateOperation from AbstractDocumentProvider which tries to run a workspace task with *null* rule). The null rule is exact where the problem is. Because there is "no rule", jobManager.beginRule(null, monitor); will NOT show any progress dialog and the code in WorkManager.checkIn(ISchedulingRule, IProgressMonitor) will immediately try to acquire the lock which is already acquired by the build job. Supplying the current file as rule is enough to get the dialog and also the possibility to cancel editing. Right now the current state causes UI lockouts in our IDE where a build job can take not just few seconds but some hours, and this is effectively killing IDE UI... I plan to provide a patch.
See also https://github.com/eclipse/n4js/AvoidRefreshDocumentProvider/master/plugins/org.eclipse.n4js.utils.ui/src/org/eclipse/n4js/utils/ui/editor/AvoidRefreshDocumentProvider.java
New Gerrit change created: https://git.eclipse.org/r/141412
Just found that almost identical code exists in TextFileDocumentProvider, and that one don't need XText to lock out UI on trying to edit a file while build is running. Same as comment 0 works also with Java default editor. I will update the patch to fix that one too.
To reproduce it in the IDE, create breakpoint in org.eclipse.core.internal.events.BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor), run build, let the build thread stop at the breakpoint and try to play with editors.
Gerrit change https://git.eclipse.org/r/141412 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=ead7de4749a856cec4c830d7bd331961cc5dad27
Verified with I20190502-1800.
Hi Andrey, I used to work on Eclipse 4.11 and recently got to Eclipse 4.19 and 4.21. I came across an issue. If during a build (which can take more than a minute) I am editing a file which was not edited before build, a progress monitor appears and typing is not allowed until the build is done. Previously we didn't have this issue. I tried to track the issue and this led me to this bug. I understand the motivation of this bugfix, however I tried to reproduce it on Eclipse 4.11 and I wasn't able to. I tried during a 1 minute build to type in .txt file, .java file and also with the Xtext editor. None of them resulted in a GUI freeze. Could you please let me know what am I doing wrong? How can I reproduce this bug in Eclipse 4.11? Thanks, Bogdan
(In reply to Bogdan Oprea from comment #7) > Could you please let me know what am I doing wrong? How can I reproduce this > bug in Eclipse 4.11? No steps with application, but you can "emulate" slow build 1) Put a conditional breakpoint after lock.acquire(); in org.eclipse.core.internal.resources.WorkManager.checkIn(ISchedulingRule, IProgressMonitor) and add Thread.sleep(5000) in the breakpoint expression. 2) Open Java file 3) Start Project -> Clean.. -> All projects 4) Type anything in the opened java file 5) Editor / UI will be frozen with no progress dialogs etc.
(In reply to Andrey Loskutov from comment #8) > (In reply to Bogdan Oprea from comment #7) > > Could you please let me know what am I doing wrong? How can I reproduce this > > bug in Eclipse 4.11? > > No steps with application, but you can "emulate" slow build > > 1) Put a conditional breakpoint after lock.acquire(); in > org.eclipse.core.internal.resources.WorkManager.checkIn(ISchedulingRule, > IProgressMonitor) and add Thread.sleep(5000) in the breakpoint expression. > 2) Open Java file > 3) Start Project -> Clean.. -> All projects > 4) Type anything in the opened java file > 5) Editor / UI will be frozen with no progress dialogs etc. But is this something that can be achieved from a user point of view? Can a user really end up in this situation? Considering that adding breakpoints is not something they can do.
(In reply to Bogdan Oprea from comment #9) > But is this something that can be achieved from a user point of view? > Can a user really end up in this situation? Considering that adding > breakpoints is not something they can do. The breakpoint only "emulates" slow work behind. So imagine builders do that slow work instead of the breakpoint, and you will answer your question. And for sure there are many ways how some build / file / system IO related operation can be slow.
