Community
Participate
Working Groups
For the last year or two I have been experiencing annoying problems whereby selecting an editor tab sometimes results in the selected editor being split off into a separate editor stack. I wondered if this was a Windows change or my ageing fingers. Eventually I conclude it is a bug. Semi-repro: in an editor stack with multiple editors, left button down on an editor tab, then slowly move down to the editor. Almost as soon as the mouse enters the editor area the editor split occurs. Really very soon and after very little movement. I therefore suspect that my problem occurs because I am moving the mouse a bit while clicking the tab and by the time the split decision is made the mouse has moved into the editor region. Solution 1: make sure that the mouse down position is used for all decisions so that the mouse up position and subsequent movement is irrelevant to the editor stack update. Solution 2: introduce much more position/time hysteresis in the activation of editor splitting. i.e. do not offer an editor split till a second has elapsed. Plenty of time for mouse up to occur.
(In reply to Ed Willink from comment #0) > For the last year or two I have been experiencing annoying problems whereby ... And I have finally identified another one as bad ergonomics rather than decrepid user. In the JUnit view: left button down on the recent runs menu. Move cursor a couple of pixels. Export is highlighted. left button up Irritation; a useless export dialog opens when I wanted to browse the recent runs. Since there are now two examples of bad behaviour as a result of the button up position being used to conflict with the button down location and so irritate the user, I think this merits CRITICAL. It is of course a REGRESSION wrt 3.x.
Moving to JDT UI, AFAIK they own the JUnit view.
(In reply to Lars Vogel from comment #2) > Moving to JDT UI, AFAIK they own the JUnit view. Why? This seems like possibly an SWT bug wrt button up position processing. But more likely a platform UI bug, since it is both JUnit menu and Editor Frame.
Sorry, I can't reproduce this using Windows 7 and 4.6 M6. Moving back to look at scenarios from comment 0 again. Are you still using Windows NT as indicated above?
Windows 10. For the JUnit repro to work, the vertical size of the recent runs menu must be larger than the distance to the bottom of the screen. This causes the menu to appear above rather than below the button down position. When above, the cursor is ready to accidentally select the bottom entry.
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.
Bug 575873 and its numerous references seem to indicate that the sheet tabs are the source of manychallenges on Windows. Hopefully the fixes for the relevant bugs fix this one too.
