Bugzilla – Full Text Bug Listing
| Summary: | Delete key deleting wrong project in Package Explorer | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | John Arthorne <john.arthorne> | ||||||||||||
| Component: | UI | Assignee: | Paul Webster <pwebster> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | critical | ||||||||||||||
| Priority: | P2 | CC: | daniel_megert, Mike_Wilson, pwebster, remy.suen, tom.schindl | ||||||||||||
| Version: | unspecified | ||||||||||||||
| Target Milestone: | 4.1 RC4 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Windows 7 | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
John Arthorne
Created attachment 186041 [details]
Screen shot
Did you have that project selected in another view? When you select something else again, does the problem fix itself? This might be the same issue as bug 333390. No, I had no other views open containing projects. Only Package Explorer, Outline, Debug, JUnit, and Variables views open. Messing around with the selection didn't seem to have any effect. The selection seemed to be "stuck" on that single project no matter what I did. I eventually restarted to get things working again. John got into this state again just now. The deletion action is fine in the 'Project Explorer' and interestingly enough, F2 works in the 'Package Explorer' also so it would imply that only the delete action for that particular view is dead. I was in this state, although closing and re-opening the PkgExp fixed it. It uses org.eclipse.jdt.internal.ui.refactoring.reorg.DeleteAction as the action for the delete key (and delete menu item, which I found to have the exact same problem) PW To give an update, I get into this state almost every day (as recently as I20110123). I tried using the Project Explorer instead of the Package Explorer but I get the problem in both views. I believe I just hit another manifestation of this bug. I selected a couple of files in the Project Explorer, and did Export > As Archive. I clicked finish, only to discover later that the zip file contained a *different* plugin. Somehow the selection from the Project Explorer didn't carry over to the wizard. I repeated the same steps and got the same error, indicating that the selection of the Project Explorer was permanently stuck at some old value. John says that he hasn't seen this in quite some time...I'll mark it as FIXED and we'll test this in the RC candidate...it's not just a matter of firing it up and trying the scenario, it was some sort of state that you could get into after a period of use... John please re-open (and ping me) if this ever shows up again for you. I saw this problem yesterday in our latest builds. PW Obviously, this is serious. Increasing Importance. I just hit this again in I20110516-2200. In case there is a pattern that emerges, this time the selection was stuck permanently on a build.properties file. (In reply to comment #11) > I just hit this again in I20110516-2200. In case there is a pattern that > emerges, this time the selection was stuck permanently on a build.properties > file. Was it 'Delete' or 'Export' or a completely different action? I've seen it most recently, so I'm running 4.1 as a debug server. If I hit the problem again, I can connect from another 4.1 instance and hopefully debug. PW (In reply to comment #12) > (In reply to comment #11) > > I just hit this again in I20110516-2200. In case there is a pattern that > > emerges, this time the selection was stuck permanently on a build.properties > > file. > > Was it 'Delete' or 'Export' or a completely different action? Delete. I've only ever seen the problem once during export. This is possibly because I delete far more often than export. I just had this very problem - thank god i already committed the project to my local git-repo because I didn't read the dialog box appropriately and so wiped the project from my disk Created attachment 196604 [details]
Execute in context v01
Execute the package explorer delete in the correct context.
PW
Created attachment 196609 [details]
Execute in context v02
Same again, but using a utility method to add the item interfaces to the static context.
PW
(In reply to comment #17) > Created attachment 196609 [details] > Execute in context v02 I've released this, as the framework was not honouring the "executeInContext(*)" request. PW A new test failure appeared in the I20110526-0630 build as a result of changes from this bug. java.lang.NullPointerException at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.addParms(HandlerServiceImpl.java:72) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:127) at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:371) at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:352) at org.eclipse.jdt.ui.tests.leaks.JavaLeakTest.testJavaEditorActionDelegate(JavaLeakTest.java:462) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:416) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:249) at org.eclipse.test.UITestApplication$2.run(UITestApplication.java:197) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3561) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3210) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:944) (In reply to comment #19) > A new test failure appeared in the I20110526-0630 build as a result of changes > from this bug. > > java.lang.NullPointerException > at I've released a fix for this, and we'll probably spin a new build today. PW Created attachment 196687 [details]
Execute in context v03
Paul, I suggest disposing the static contexts when we're done with them. Right now there are too many of them lying around and it fills the 'Contexts' view up.
We should also always be passing a "throw away" context to the EHS as the EHS will manipulate the contents of this context directly.
Created attachment 196692 [details]
Execute in context v04
Catch some additional areas where we create a throw-away context.
PW
We're going to have to keep our eyes out for this in our testing in RC4 PW I haven't been able to reproduce this since the change. We'll re-open if it re-occurs. PW |