Community
Participate
Working Groups
Must be a regression from some recent commits, tested with latest on nightly build. Change some files. Use drag/drop to move to staged area. Commit. Staged files are still in staged area and double click on them opens a warning that the file is not staged. Clicking "refresh" in the staging view doesn't change anything. Project explorer shows clean state. @Matthias: can we please add "4.5" as target to bugzilla?
Sorry, I've missed: actually staging view is entirely unusable anymore after commit, and the error log shows multiple errors like this: Caused by: org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4533) at org.eclipse.swt.SWT.error(SWT.java:4448) at org.eclipse.swt.SWT.error(SWT.java:4419) at org.eclipse.swt.widgets.Widget.error(Widget.java:483) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:420) at org.eclipse.swt.widgets.Widget.getData(Widget.java:509) at org.eclipse.egit.ui.internal.staging.StagingView$TreeItemVisitor.traverse(StagingView.java:2306) at org.eclipse.egit.ui.internal.staging.StagingView.setStagingViewerInput(StagingView.java:1972) at org.eclipse.egit.ui.internal.staging.StagingView.access$78(StagingView.java:1950) at org.eclipse.egit.ui.internal.staging.StagingView$58.run(StagingView.java:3406) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182)
Looks like a regression from bug 451216.
Ed: would it maybe be safer to traverse the model to find the item to select? If needed, expansion state could also be maintained in the model via a TreeListener.
Small correction: "Commit and Push" shows the problem. "Commit" is OK.
(In reply to Thomas Wolf from comment #3) > Ed: would it maybe be safer to traverse the model to find the item to > select? If needed, expansion state could also be maintained in the model via > a TreeListener. There's already a guard to check for null data at org.eclipse.egit.ui.internal.staging.StagingView$TreeItemVisitor.traverse(StagingView.java:2306) because of phantom nodes in the tree: if (treeItem.getData() != null && visit(treeItem)) { I would try adding a disposed check. if (!treeItem.isDisposed() && treeItem.getData() != null && visit(treeItem)) { traversePrecedingSiblings(treeItem); } I tried to reproduce this with the latest code base, doing a commit and push to a local test git repository, but could not reproduce it. Thomas, are you able to reproduce the problem? Can you give me the steps that reproduces the problem so I can inspect the issue properly?
(In reply to Andrey Loskutov from comment #0) > @Matthias: can we please add "4.5" as target to bugzilla? target milestone 4.5 was already existing, I added version 4.5 so that users can report bugs for 4.5
I can't reproduce this problem on Mac using current master on Neon
Apologies, I think now I've nailed it down. It looks like this can be reproduced only if the staging view has small size so that unstaged area has a scrollbar shown (just modify more files to see the scrollbar). Do *not* change the view size at that point! Now drag drop everything to the staged area (which should have a scrollbar now), and commit *or* commit & push. Last one is not relevant, it can be reproduced on any local repo without remote. So it looks like the scrollable causes the troubles here.
Which platform?
(In reply to Thomas Wolf from comment #9) > Which platform? I'm on GTK2 2.24.22 RHEL 7.
New Gerrit change created: https://git.eclipse.org/r/81070
(In reply to Eclipse Genie from comment #11) > New Gerrit change created: https://git.eclipse.org/r/81070 This fixes my issues, but I have no clue why a treeItem can be disposed at that point.
Yes, I had a feeling it's a Linux-only problem. It seems to me more of an SWT/GTK bug, i.e., one would never expect the Tree to return a disposed widget as the top widget. After all how can a disposed widget possibly be in the Tree at all, let alone at the top. But the guard seems the simplest way to go, and if that's not really needed on other platforms, it does no harm either.
Gerrit change https://git.eclipse.org/r/81070 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=310f37ca03d89d3a498c94912a7790cd4e6c9050
(In reply to Eclipse Genie from comment #14) > Gerrit change https://git.eclipse.org/r/81070 was merged to [master]. > Commit: > http://git.eclipse.org/c/egit/egit.git/commit/ > ?id=310f37ca03d89d3a498c94912a7790cd4e6c9050 I've merged this workaround now for egit. I can reproduce the issue on GTK2/GTK3 with both 4.6.0 and 4.7 HEAD of SWT and I'm going to open an SWT bug.
(In reply to Andrey Loskutov from comment #15) > I can reproduce the issue on > GTK2/GTK3 with both 4.6.0 and 4.7 HEAD of SWT and I'm going to open an SWT > bug. Correction: it is broken on 4.7 only, I've opened bug 501420 for SWT.
