Community
Participate
Working Groups
When an eclipse project is closed the CloseResourceAction.run() method takes care of dirty editors associated with the project to be closed by asking the user if they should be saved via a dialog. If the user accepts the editors are saved and closed. However none dirty editors are left open but should be closed. When deleting a project neither dirty nor non dirty editors associated with the project to be deleted are closed by eclipse.
*** Bug 41432 has been marked as a duplicate of this bug. ***
There exists IDE.saveAllEditors method and there is a need for an IDE.closeAllEditors(IResource[], boolean save) method as well to support fixing this type of problem
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
*** Bug 52279 has been marked as a duplicate of this bug. ***
See bug 29570 for project deletion case.
*** Bug 101391 has been marked as a duplicate of this bug. ***
*** Bug 296920 has been marked as a duplicate of this bug. ***
Please ignore comment 7. The workbench should simply close the affected editors before deleting or closing a project. Otherwise, the open editors close when their files go away which makes the workbench trying to activate the next editor (for which the file is already gone) and hence results in errors. Another way to improve this would be to fix bug 29570 which asks not to activate the editor part if its input doesn't exist.
*** Bug 153692 has been marked as a duplicate of this bug. ***
Come on guys! Thisis so depressing. 7 years and still no progress on this one?
(In reply to comment #10) > The workbench should simply close the affected editors before deleting or > closing a project. Wouldn't we be forced to cause bundle initialization on every editor on the basis that we need to load and check whether their inputs are related to the project being closed or deleted? (In reply to comment #12) > Come on guys! Thisis so depressing. 7 years and still no progress on this one? I'm afraid the age of a bug is not a good indication of its importance and/or its severity.
> I'm afraid the age of a bug is not a good indication of its importance and/or > its severity. I actually think the reason why this bug hasn't been fixed so far is because of its non-severity. The thing is it's a harmless bug but it is so distractive. I say it is so distractive because I can't remember any of the other IDEs (VisualAge, Visual Cafe, JBuilder, NetBeans, JDeveloper, IDEA, CodeGuide, etc.) I have used in the past have had a similar bug.
*** Bug 329019 has been marked as a duplicate of this bug. ***
*** Bug 18421 has been marked as a duplicate of this bug. ***
*** Bug 168554 has been marked as a duplicate of this bug. ***
Still experiencing the same thing. I think that workflow bugs like this one should be as important as security or crashes. The more quickly this one is resolved the speedier development will be. This means that the fixes of other bugs will be resolved quicker if this one goes away.
Without looking at the code the only "safe" way I can think of resolving this is to check all available editors' inputs and determine whether they're a FileEditorInput or not. Based on that information we can restore them (which shouldn't cause bundle activation as org.eclipse.ui.ide should already have been activated long ago) and compare their files with the project(s) being closed/deleted and close the owning editor if applicable. I would be willing to look at patches contributed from the community that implements the above or some other solution that is superior to the above.
Whenever I use Eclipse I can find a bug or two per day. As bugs like this are ignored for more than 7 years, I cannot even be bothered to submit bug reports anymore. > Without looking at the code the only "safe" way I can think of resolving this is to check all available editors' inputs and determine whether they're a FileEditorInput or not. Based on that information we can restore them (which shouldn't cause bundle activation as org.eclipse.ui.ide should already have been activated long ago) and compare their files with the project(s) being closed/deleted and close the owning editor if applicable. I don't know much about Eclipse's architecture, but an elegant way of doing this, if permitted by Eclipse's architecture, is to make editors implement a ProjectListener or something that listen to projectClosed/projectDeleted events and then close themselves.
(In reply to comment #20) > I don't know much about Eclipse's architecture, but an elegant way of doing > this, if permitted by Eclipse's architecture, is to make editors implement a > ProjectListener or something that listen to projectClosed/projectDeleted events > and then close themselves. Behrang, the editors are already listening for this event. The issue is that editors do not get reinstantiated when Eclipse restarts until the user actually activates them (to support lazy-loading). As a result, the editors' code for attaching the listener never gets called.
*** Bug 393718 has been marked as a duplicate of this bug. ***
*** Bug 346220 has been marked as a duplicate of this bug. ***
I would also like to see this fixed. I have an RCP product that has this issue and it's confusing for my users. When a project is deleted or closed, they expect all related editors to be closed too, and not to remain in error state with a confusing error message.
CQ:WIND00383632
I agree it would be nice to see this fixed. nasty empty editor with lots of red X's :) Closing https://bugs.eclipse.org/bugs/show_bug.cgi?id=400019 as duplicate of this.
*** Bug 400019 has been marked as a duplicate of this bug. ***
*** Bug 409782 has been marked as a duplicate of this bug. ***
This issue is ten years old and the problem has been independently found and reported five times. It would be great if someone with the required expertise and committer status could give this some attention.
This is marked as helpwanted. I can guide someone that wants to contribute a patch, but I won't have time to look at this for some time. PW
*** Bug 40795 has been marked as a duplicate of this bug. ***
*** Bug 458266 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/41675
New Gerrit change created: https://git.eclipse.org/r/41796
Gerrit change https://git.eclipse.org/r/41675 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ea1e252c1a7f31b29af223acd8ce637d078728e0
(In reply to Eclipse Genie from comment #34) > New Gerrit change created: https://git.eclipse.org/r/41796 The cleanup patch in not yet applied, it has a rebase conflict.
Gerrit change https://git.eclipse.org/r/41796 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=838b01efe9e41c62164675b933f300bf30b6b876
Thanks Andrey, can you also provide a N&N for this change?
.
(In reply to Lars Vogel from comment #38) > Thanks Andrey, can you also provide a N&N for this change? See https://git.eclipse.org/r/42972
Verified in I20150318-2000
*** Bug 462043 has been marked as a duplicate of this bug. ***
*** Bug 464848 has been marked as a duplicate of this bug. ***
Hello, I'm facing a similar issue. Since the issue is fixed, which build/version of Eclipse can I find the fix in? Currently I'm using Eclipse Java EE IDE for Web Developers. Version: Luna Service Release 2 (4.4.2) Build id: 20150219-0600 Thanks & Regards, Shreya
(In reply to Shreya Dixit from comment #45) > Hello, > > I'm facing a similar issue. > Since the issue is fixed, which build/version of Eclipse can I find the fix > in? > Currently I'm using Eclipse Java EE IDE for Web Developers. > > Version: Luna Service Release 2 (4.4.2) > Build id: 20150219-0600 > > Thanks & Regards, > Shreya You can either switch to 4.5 RC3: https://www.eclipse.org/downloads/index-developer-default.php Or wait until June 24 when 4.5 is officially released.
