Community
Participate
Working Groups
Created attachment 280894 [details] NewWizard affected category "Eclipse 4" I encoutered a strange behavior in the NewWizard when opening the "Eclipse 4" category. The first time opening this category causes the subelements to show, but only for a short period of time (~100ms). Then the category gets closed again - without any user interaction. The second attempt to open the category will result in the expected behavior: the subelements stay visible. All other categories are working as expected. Steps to reproduce: 1. Open Eclipse SDK (tested with 2019-09 and 4.14RC1) with installed Eclipse e4 Tools 2. Open the NewWizard via File -> New -> Other... 3. Open the category/folder "Eclipse 4" (with double click or a click on the expand arrow) 4. Watch the behavior explained above.
The same happens for the "Examples" category. Both cases only if not another category is opened first. Both "Eclipse 4" and "Examples" only contain sub-categories.
(In reply to Rolf Theunissen from comment #1) > The same happens for the "Examples" category. Both cases only if not another > category is opened first. > > Both "Eclipse 4" and "Examples" only contain sub-categories. Happens on Windows and Linux.
I wondering nobody noticed this yet. Looks like this is coming from bug 257176. If I remove focusLost() handler from filtered text, everything works as expected (org.eclipse.ui.dialogs.FilteredTree.createFilterText(...).new FocusAdapter() {...}.focusLost(FocusEvent)). The handler triggers tree refresh that killed the expanded state.
I was able to see it on all versions back to 4.8, where we added "Eclipse 4" category.
(In reply to Andrey Loskutov from comment #3) > I wondering nobody noticed this yet. Looks like this is coming from bug > 257176. > If I remove focusLost() handler from filtered text, everything works as > expected (org.eclipse.ui.dialogs.FilteredTree.createFilterText(...).new > FocusAdapter() {...}.focusLost(FocusEvent)). The handler triggers tree > refresh that killed the expanded state. So we remove the focusLost handler?
(In reply to Lars Vogel from comment #5) > (In reply to Andrey Loskutov from comment #3) > > I wondering nobody noticed this yet. Looks like this is coming from bug > > 257176. > > If I remove focusLost() handler from filtered text, everything works as > > expected (org.eclipse.ui.dialogs.FilteredTree.createFilterText(...).new > > FocusAdapter() {...}.focusLost(FocusEvent)). The handler triggers tree > > refresh that killed the expanded state. > > So we remove the focusLost handler? I didn't said that. I only wanted to show *what* is the root cause for the bug. One need to understand first, *why* it was needed (see bug 257176) and if there is still need for that code. If the code isn't necessary anymore we can remove it, if it is still needed, one should find a better fix for bug 257176.
If I read it right (bug 257176 comment 7), we might have dependency on bug 4655 due some Windows behavior. May be bug 4655 is obsoleted already, one need to check that.
Anyone working on this? If not, please remove the target milestone.
*** Bug 561695 has been marked as a duplicate of this bug. ***
Dear Team, This issue is reproducible in our application also. Please let us know when it'll be resolved. Thanks.
(In reply to Prachi Singla from comment #10) > Dear Team, > > This issue is reproducible in our application also. Please let us know when > it'll be resolved. > > Thanks. Moreover, Isn't this case dulpicate of the below case?? https://bugs.eclipse.org/bugs/show_bug.cgi?id=430837
*** Bug 430837 has been marked as a duplicate of this bug. ***
(In reply to Prachi Singla from comment #10) > Dear Team, > > This issue is reproducible in our application also. Please let us know when > it'll be resolved. > > Thanks. When someone steps up t fix it.No ETA.
Hi, Anyone started working on this case?
(In reply to Prachi Singla from comment #14) > Hi, > > Anyone started working on this case? No, Gerrits are welcome
