Bugzilla – Full Text Bug Listing
| Summary: | [Contributions] Open Type | Search buttons interchanged | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Ed Willink <ed> | ||||||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | ben.cox, daniel_megert, krzysztof.daniel, Lars.Vogel, loskutov, marc.khouzam, markus.kell.r, pawel.1.piech, pchuong, psuzzi, pwebster, stepper, sudol.wojciech | ||||||||
| Version: | 4.3 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=463245 https://bugs.eclipse.org/bugs/show_bug.cgi?id=420956 |
||||||||||
| Whiteboard: | stalebug | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Ed Willink
> Is this a deliberate attempt to make e4 unpopular?
No, I guess it's just a reflection of e4's quality...
I think the bug introduced in _4.3M3_, because I can't seem to reproduce with M2. Another bizzare detail is that when the IDE is started with a clean workspace, the ordering is correct, only when re-using the workspace ordering is reversed. Also, not only debug actions are affected, I see that "Open Type" and "Search" actions traded places as well. OK, let's move this to Platform UI. The orders must be like in 3.x everywhere. (In reply to comment #0) > and worse the ordering of Step-Into, Step-Over and Step-Return has been > reversed. Today (after restarting) the ordering is back to normal. (In reply to comment #2) > only when re-using the workspace ordering is reversed. Thanks for the conformation. This seems to be the key. It is a 3.8.1 to 4.3M3 workspace re-use migration problem, possibly aggravated by doing 3.8.1 to 4.3M3 to 3.8.1 to 4.3M3 to check up on strange EGIT behaviours. *** Bug 405969 has been marked as a duplicate of this bug. *** Is this likely to be addressed in Kepler? I can easily change the ordering of the declaration of actions in the action set, but there is still going to be an inconsistency between when launching with a new workspace or not. (In reply to comment #6) > Is this likely to be addressed in Kepler? I'm really surprised that what seems like a trivial but MAJOR fix has been allowed out unfixed. I'm inclined now to WONTFIX since there will Kepler users who gow used to the changed ordering. Certainly I have been using random ordering (outer/inner Eclipse) for so long now that I frequently have to consult the hover text to tell me which button is which. The icons no longer make any sense to me. If I don't use the hover text I frequently make the wrong selection. (In reply to comment #6) > Is this likely to be addressed in Kepler? I can easily change the ordering > of the declaration of actions in the action set, but there is still going to > be an inconsistency between when launching with a new workspace or not. I work on two different machines both of wose workspaces ahve been upgraded over many months if not years. One has one order, the other is reversed. No wonder I'm confused/depressed. (In reply to comment #8) > (In reply to comment #6) > > Is this likely to be addressed in Kepler? I can easily change the ordering > > of the declaration of actions in the action set, but there is still going to > > be an inconsistency between when launching with a new workspace or not. > > I work on two different machines both of wose workspaces ahve been upgraded > over many months if not years. > > One has one order, the other is reversed. No wonder I'm confused/depressed. Reset Perspective... might bring it back in order. Using new workspaces, the order is the same for 3.x and 4.x. Created attachment 233701 [details]
Screenshot
Steps in 4.3 (no older release necessary to reproduce, just a restart):
- launch new workspace, close Welcome, open Debug perspective
=> order is correct
- File > Restart
=> order is mangled
The mangling only seems to happen when you restart while the Debug perspective is open.
WORKAROUND: Switch to Java perspective before shutting down Eclipse.
(In reply to comment #10) > Created attachment 233701 [details] > Screenshot > > Steps in 4.3 (no older release necessary to reproduce, just a restart): > > - launch new workspace, close Welcome, open Debug perspective > => order is correct > > - File > Restart > => order is mangled > > The mangling only seems to happen when you restart while the Debug > perspective is open. And if so, the perspective is corrupt forever in its current window, i.e. resetting the perspective does not help. Opening the Debug perspective in a new window fixes the problem. *** Bug 414395 has been marked as a duplicate of this bug. *** This bug may be related to bug 399401. Are you really not going to fix this for Luna? It was bad enough this UI being broken in Kepler, but Luna too? Not in Luna, unless it gets fixed as part of Bug 385565 PW Wojtek, Please verify if it is still valid. If not, I will remove it from the priority list of Mars thanks, Daniel I tested Eclipse 4.4.0, 4.4.1 and 4.5 I20141027-2000. The order of Step Into/Over/Return buttons is now correct and stay correct after restart, but the problem with order of "Search" and "Open Type" buttons still exists. (In reply to Wojciech Sudol from comment #17) I tested Eclipse 4.5M3. Markus' repro from Comment #10 doesn't seem to be repro any more. I'll keep my eye out to see if it's stable, but I've got used to it being wrong now. Everything is OK now in 4.5 M5 (open type/search order is OK, step in/out too). Closing as fixed, but I have no idea where the fix was actually introduced. Using 4.5 M5a, I still see the problem (only checked Search / Open Type): With a new workspace (or new Java perspective being opened), the order is wrong: Search | Open Type After one restart it becomes correct: Open Type | Search (In reply to Dani Megert from comment #20) > Using 4.5 M5a, I still see the problem (only checked Search / Open Type): > > With a new workspace (or new Java perspective being opened), the order is > wrong: > Search | Open Type > > After one restart it becomes correct: Open Type | Search Dani, which product are you using? Can the problem you still observe (or my own state I've observed) be caused by some 3rd party plugins redefining the toolbar definitions? (In reply to Andrey Loskutov from comment #21) > (In reply to Dani Megert from comment #20) > > Using 4.5 M5a, I still see the problem (only checked Search / Open Type): > > > > With a new workspace (or new Java perspective being opened), the order is > > wrong: > > Search | Open Type > > > > After one restart it becomes correct: Open Type | Search > > Dani, which product are you using? Can the problem you still observe (or my > own state I've observed) be caused by some 3rd party plugins redefining the > toolbar definitions? That could be. I'm using "our" plain SDK build: http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M5a-201502031300/ Created attachment 250691 [details] Screenshot on Linux 64 bit gtk SDK build of M5a (In reply to Dani Megert from comment #22) > (In reply to Andrey Loskutov from comment #21) > > (In reply to Dani Megert from comment #20) > > > Using 4.5 M5a, I still see the problem (only checked Search / Open Type): > > > > > > With a new workspace (or new Java perspective being opened), the order is > > > wrong: > > > Search | Open Type > > > > > > After one restart it becomes correct: Open Type | Search > > > > Dani, which product are you using? Can the problem you still observe (or my > > own state I've observed) be caused by some 3rd party plugins redefining the > > toolbar definitions? > > That could be. I'm using "our" plain SDK build: > http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M5a-201502031300/ Just tried exact this "plain" build out - it works fine out of the box, see attached picture. BTW I'm using 64 bit Linux gtk build and GTK3 on KDE. Any ideas what can be wrong with your build - I guess Windows or Mac? (In reply to Andrey Loskutov from comment #23) > > That could be. I'm using "our" plain SDK build: > > http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M5a-201502031300/ > > Just tried exact this "plain" build out - it works fine out of the box, I don't think so ;-). I assume that you tried with an existing workspace instead of a new one, see comment 20. Created attachment 250702 [details]
Picture on Windows 7 and Ubuntu
(In reply to Dani Megert from comment #24) > (In reply to Andrey Loskutov from comment #23) > > > That could be. I'm using "our" plain SDK build: > > > http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M5a-201502031300/ > > > > Just tried exact this "plain" build out - it works fine out of the box, > > I don't think so ;-). I assume that you tried with an existing workspace > instead of a new one, see comment 20. I've used new workspace and fresh install - everything from scratch. (In reply to Andrey Loskutov from comment #26) > (In reply to Dani Megert from comment #24) > > (In reply to Andrey Loskutov from comment #23) > > > > That could be. I'm using "our" plain SDK build: > > > > http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M5a-201502031300/ > > > > > > Just tried exact this "plain" build out - it works fine out of the box, > > > > I don't think so ;-). I assume that you tried with an existing workspace > > instead of a new one, see comment 20. > > I've used new workspace and fresh install - everything from scratch. I also managed to see it correct on one install. I might depend on the Welcome page (Browser widget) and how it is closed (timing issue?). When I add -Dorg.eclipse.swt.browser.DefaultType=mozilla -Dorg.eclipse.swt.browser.XULRunnerPath=/none it starts to fail again. (In reply to Dani Megert from comment #20) > Using 4.5 M5a, I still see the problem (only checked Search / Open Type): > > With a new workspace (or new Java perspective being opened), the order is > wrong: > Search | Open Type > > After one restart it becomes correct: Open Type | Search Can't reproduce with 4.5.0.N20150325-2000 (In reply to Lars Vogel from comment #28) > (In reply to Dani Megert from comment #20) > > Using 4.5 M5a, I still see the problem (only checked Search / Open Type): > > > > With a new workspace (or new Java perspective being opened), the order is > > wrong: > > Search | Open Type > > > > After one restart it becomes correct: Open Type | Search > > Can't reproduce with 4.5.0.N20150325-2000 Same here using N20150224-2000. (In reply to Dani Megert from comment #29) > (In reply to Lars Vogel from comment #28) > > (In reply to Dani Megert from comment #20) > > > Using 4.5 M5a, I still see the problem (only checked Search / Open Type): > > > > > > With a new workspace (or new Java perspective being opened), the order is > > > wrong: > > > Search | Open Type > > > > > > After one restart it becomes correct: Open Type | Search > > > > Can't reproduce with 4.5.0.N20150325-2000 > > Same here using N20150224-2000. We probably closed it by clicking on the arrow. When I click on the [x] immediately after startup, it is still swapped. This is with eclipse-SDK-N20150416-2000-win32-x86_64. (In reply to Dani Megert from comment #30) > (In reply to Dani Megert from comment #29) > > (In reply to Lars Vogel from comment #28) > > > (In reply to Dani Megert from comment #20) > > > > Using 4.5 M5a, I still see the problem (only checked Search / Open Type): > > > > > > > > With a new workspace (or new Java perspective being opened), the order is > > > > wrong: > > > > Search | Open Type > > > > > > > > After one restart it becomes correct: Open Type | Search > > > > > > Can't reproduce with 4.5.0.N20150325-2000 > > > > Same here using N20150224-2000. > > We probably closed it by clicking on the arrow. When I click on the [x] > immediately after startup, it is still swapped. This is with > eclipse-SDK-N20150416-2000-win32-x86_64. Using same build N20150413-2000 (different natives of course) on Windows 7 and RHEL 7 I see the issue only on Win 7, and only if I use [x] close button on the welcome view tab to close the welcome view. If I use "restore" button to un-maximize the welcome view, the buttons order is OK. But as said, this is visible only on Windows 7, on RHEL I don't see any "bad" ordering at all. So it seems to be part closing/SWT related - the order/amount of events can depend on the SWT platform code (e.g. extra refreshes or events here and there) after part closing. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |