Bugzilla – Full Text Bug Listing
| Summary: | Ctrl+PageDown doesn't work multiple times in Classic theme | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> |
| Component: | SWT | Assignee: | Carolyn MacLeod <carolynmacleod4> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | carolynmacleod4, daniel_megert, emoffatt, gheorghe, pwebster, Silenio_Quarti |
| Version: | 4.3 | ||
| Target Milestone: | 4.2.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Markus Keller
FYI, the following SWT-only CTabFolder snippet works fine every time.
(Tabs are numbered so that it is easy to know if you arrived at the correct tab no matter how many ctrl+page downs you quickly type).
import org.eclipse.swt.*;
import org.eclipse.swt.widgets.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.custom.*;
public class CTabFolderManyTabsTest {
public static void main(String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
shell.setLayout(new FillLayout());
CTabFolder tabFolder = new CTabFolder(shell, SWT.FLAT);
for (int i = 0; i < 12; i++) {
CTabItem item = new CTabItem(tabFolder, SWT.NULL);
item.setText("Tab " + i);
Text itemText = new Text(tabFolder, SWT.MULTI);
itemText.setText("\n\tText control for tab " + i + "\n\n\n");
item.setControl(itemText);
}
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
}
}
(Works fine with: StyledText itemText = new StyledText(tabFolder, SWT.MULTI); also... which would slightly more closely match the editor part). Wow - you say it rarely works for you, but I tried to see the failure in my running eclipse, and I always hit the correct tab. I am only doing a maximum of 6 ctrl+tabs in a row, and there are only 6 visible editor tabs. I am running: Version: 4.3.0 Build id: I20121031-2000 Sorry, I only wrote "Classic theme" in the subject. Did you really try it with the Classic theme? When I perform the steps in bug 394109 and then switch to the Classic theme and restart, I can often reproduce. When I enable the Breadcrumb and then give focus back to the editor (e.g. via Esc), then it rarely works correctly. > If you do it slowly, you can see that the Minimize button is focused at one > point. If the overflow chevron is shown, then that one also quickly gets focus. I guess the bug is not in SWT, but in some async event handling or firing in E4. (In reply to comment #3) > Wow - you say it rarely works for you, Same here, but I need to do it really fast to break it and you need to be in the 'Classic' theme. Ah - I see the failure now. Sorry about that - I haven't used Classic theme in a long time.
For what it's worth, here's a newer little SWT-only snippet that emulates "Classic" theme (with swoosh-style tabs, selected tab gradient, chevron, min and max). I cannot get this snippet to fail.
import org.eclipse.swt.*;
import org.eclipse.swt.widgets.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.custom.*;
import org.eclipse.swt.graphics.*;
public class CTabFolderManyTabsTest {
public static void main(String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
shell.setLayout(new FillLayout());
CTabFolder tabFolder = new CTabFolder(shell, SWT.NONE);
tabFolder.setSimple(false);
tabFolder.setMaximizeVisible(true);
tabFolder.setMinimizeVisible(true);
tabFolder.setSelectionBackground(new Color[] {
display.getSystemColor(SWT.COLOR_WHITE),
display.getSystemColor(SWT.COLOR_WHITE),
display.getSystemColor(SWT.COLOR_BLUE)},
new int[] {50, 100}, true);
for (int i = 0; i < 12; i++) {
CTabItem item = new CTabItem(tabFolder, SWT.NULL);
item.setText("Tab " + i);
StyledText itemText = new StyledText(tabFolder, SWT.MULTI);
itemText.setText("\n\tText control for tab " + i + "\n\n\n");
item.setControl(itemText);
}
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
}
}
> For what it's worth, here's a newer little SWT-only snippet that emulates > "Classic" theme. Thanks, I could use that for bug 377113... You're welcome. :)
Here's another SWT-only snippet that emulates Eclipse's "asynchronously force focus to the CTabItem's control when the CTabItem is activated or selected" UI behavior. Not sure if this snippet is helpful... it still does not fail no matter how fast I try to type ctrl+page up/down. So something more is going on behind the scenes in Eclipse that is causing this problem - I don't think it's in CTabFolder or SWT.
import org.eclipse.swt.*;
import org.eclipse.swt.custom.*;
import org.eclipse.swt.events.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.widgets.*;
public class CTabFolderManyTabsTest {
static boolean forceFocusOnActivate = true;
static boolean forceFocusOnSelection = true;
public static void main(String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
shell.setLayout(new GridLayout());
CTabFolder tabFolder = new CTabFolder(shell, SWT.BORDER);
tabFolder.setSimple(false);
tabFolder.setMaximizeVisible(true);
tabFolder.setMinimizeVisible(true);
tabFolder.setSelectionBackground(new Color[] {
display.getSystemColor(SWT.COLOR_WHITE),
display.getSystemColor(SWT.COLOR_WHITE),
display.getSystemColor(SWT.COLOR_BLUE)},
new int[] {50, 100}, true);
for (int i = 0; i < 12; i++) {
CTabItem item = new CTabItem(tabFolder, SWT.NULL);
item.setText("Tab " + i);
StyledText itemText = new StyledText(tabFolder, SWT.MULTI);
itemText.setText("\n\tText control for tab " + i + "\n\n\n");
item.setControl(itemText);
}
tabFolder.addTraverseListener(new TraverseListener() {
public void keyTraversed(TraverseEvent e) {
switch (e.detail) {
case SWT.TRAVERSE_ARROW_NEXT:
case SWT.TRAVERSE_ARROW_PREVIOUS:
forceFocusOnActivate = false;
forceFocusOnSelection = false;
break;
}
}
});
tabFolder.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(SelectionEvent e) {
if (forceFocusOnSelection) focusOn(e.widget);
forceFocusOnSelection = true;
}
});
tabFolder.addListener(SWT.Activate, new Listener() {
public void handleEvent(Event e) {
if (forceFocusOnActivate) focusOn(e.widget);
forceFocusOnActivate = true;
}
});
tabFolder.addKeyListener(new KeyAdapter() {
public void keyPressed(KeyEvent e) {
if (e.keyCode == SWT.CR) {
focusOn(e.widget);
forceFocusOnSelection = true;
}
}
});
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
}
// Emulate Eclipse's "asynchronously force focus to CTabItem's control" behavior
static void focusOn(final Widget widget) {
widget.getDisplay().asyncExec(new Runnable() {
public void run() {
CTabFolder tf = (CTabFolder) widget;
CTabItem ti = tf.getSelection();
if (ti != null) {
Control c = ti.getControl();
if (c != null && !c.isDisposed()) {
c.setFocus();
}
}
}
});
}
}
(In reply to comment #8) I also couldn't reproduce with this snippet, but I saw that the focus flashing on the Minimize button also happens with this snippet. To make it more apparent, change the asyncExec to timerExec(2000, ...). And the flashing on the chevron can be seen if you add a Thread.sleep(1000); at the beginning of focusOn(..) and then press Ctrl+PageDown twice. Neither of these problems shows up in R3_8_maintenance. Fixed in master: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=bc7e1bc085c7d5faaae0b0da826b492f201e635a We looked at this, and discussed the "interesting focus issues" that were going on, and decided that the max, min, and chevron buttons really should not take focus. There are existing keyboard shortcuts for these buttons: - Ctrl+E for the chevron - Ctrl+M for Maximize/Restore - I don't see one for Minimize... I will open a bug to have one added I temporarily set the target milestone to 4.3M4, but we will decide in the next few days (after trying it in a build) whether to backport to 4.2.2 (it does not need to be backported to 3.8.2 because max/min/chevron were all drawn back then). Leaving open to consider backporting. (In reply to comment #10) > Fixed in master: Nope, I can still reproduce the issue that the first tab is wrongly selected when I traverse tabs. An easier-to-see variant is to open enough editors so that the chevron appears, then go to the last tab and press Ctrl+PageUp a few times. When the drow-down opens, you've hit the bug. > not take focus. There are existing keyboard shortcuts for these buttons: These shortcuts only work in Eclipse (and maybe RCP application). Shouldn't all SWT apps be accessible? > - I don't see one for Minimize... I will open a bug to have one added No need to do that. There's already a command and a menu item (in Window > Navigation) for this. There's no default shortcut, and there shouldn't be one, because this is not an often-used action. In 3.8, you can also minimize via Alt+- (regression in E4, bug exists). > Nope, I can still reproduce the issue that the first tab is wrongly selected > when I traverse tabs. I can't get the failure case to happen. > An easier-to-see variant is to open enough editors so that the chevron appears, > then go to the last tab and press Ctrl+PageUp a few times. When the drop-down > opens, you've hit the bug. The drop-down doesn't open for me. Is that a special setting in Eclipse, maybe? > These shortcuts only work in Eclipse (and maybe RCP application). > Shouldn't all SWT apps be accessible? Yes, and I need to document in CTabFolder how to add keyboard accessibility for maximize/restore/[minimize]. (CTabFolder cannot do these on its own). I don't think CTabFolder needs a keyboard shortcut to open its "native" chevron menu because Ctrl+PageUp/PageDown cycles through all of the tabs anyhow, and there is no advantage to be gained by dropping down the chevron menu. I could also document how Eclipse shows the nice filtered list when the chevron is dropped down (by either mouse or keyboard), because the filtered list is useful for keyboard users. > No need to do that. There's already a command and a menu item > (in Window > Navigation) for this. Thanks! Sounds good. (In reply to comment #12) > The drop-down doesn't open for me. Is that a special setting in Eclipse, > maybe? The drop-down should always open in Eclipse when you're on the first or last visible tab and then try to traverse to the next tab outside of the visible tab set. I don't think there's a setting to configure that. Again, it's much easier to reproduce if you slow down the Java editor a bit by enabling the Breadcrumb. > I don't think CTabFolder needs a keyboard shortcut to open its "native" > chevron menu because Ctrl+PageUp/PageDown cycles through all of the tabs > anyhow, and there is no advantage to be gained by dropping down the chevron > menu. I agree about the chevron. But it's a bit strange that additional topRight actions in the tab bar are reachable via Ctrl+Tab, but Minimize/Maximize are not. See e.g. in the CustomControlExample. There, you also see that the focus currently goes to topRight toolbar when you press Ctrl+PageDown. > The drop-down should always open in Eclipse when you're on the first or last > visible tab and then try to traverse to the next tab outside of the visible > tab set. Hmmm... I see what you mean. This behavior does not happen now with the code I released in comment 10, which is why I didn't see it. The user doesn't get the chevron menu with Ctrl+PageDown any more. Now, Ctrl+PageDown/PageUp cycles through the tabs. To get the chevron menu, use Ctrl+E. This is probably more "expected" behavior for the non-visual user. > But it's a bit strange that additional topRight actions in the tab bar are > reachable via Ctrl+Tab, but Minimize/Maximize are not. Yikes, you are right. This is very strange - I would call it a bug. Focus should not go to the top right toolbar on Ctrl+PageDown. Users are supposed to type Tab, Shift+Tab, Ctrl+Tab, or Ctrl+Shift+Tab to navigate to the toolbar. I will think about this some more. (In reply to comment #14) In Eclipse, the editor menu still shows up on Ctrl+PageDown/PageUp for me (comment 10 doesn't change this). Note that this is an Eclipse-only customization that you don't get in pure SWT examples. > > But it's a bit strange that additional topRight actions in the tab bar are > > reachable via Ctrl+Tab, but Minimize/Maximize are not. > > Yikes, you are right. This is very strange - I would call it a bug. Focus > should not go to the top right toolbar on Ctrl+PageDown. That's not what I meant, but you're right, that's another bug. In the CustomControlExample, I see this independent of comment 10 (but only if I start with the focus in the tab item's content control, not when focus is on the tab itself. In the SDK, it's not visible, since the focus is always set back into the tab content. > Users are supposed to type Tab, Shift+Tab, Ctrl+Tab, or Ctrl+Shift+Tab to > navigate to the toolbar. Yes, that's what I meant. But I also consider the Minimize/Maximize buttons to be part of the toolbar, so treating Min/Max different from CTabFolder#setTopRight(..) items is strange. New commit, overrides the one in comment 10. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=b31a2c4fef115f61f56aab574a9b54fe849df0f4 This one lets min/max and chevron take focus again (so that I don't get in trouble with the accessibility people <grin>). It fixes the strange toolbar-gets-focus-on-page-traversal behavior discussed in comment 14 and comment 15. And I believe it fixes the original problem of getting lost when traversing pages very quickly. (At least, I tried it many times with 10 ctrl+pagedowns in a row, and I could not make it fail). Please try this in tomorrow's integration build, when it is available. Note that I have only tried it on Windows so far - I will try it on Mac and Linux tomorrow. I am leaving this bug open for now - please let me know what you think. (In reply to comment #16) The focus flashing on the toolbar button is gone, and the buttons are accessible via Ctrl+Tab. The fix is good for these problems. However, I don't see a change regarding the wrong tab selection on quick Ctrl+PageUp/Downs. I debugged the problem with a breakpoint in CTabFolder#setSelection(int) with condition "index == 0" and found two problems: - CTabFolder#setSelection(int) sets "selection.showing = false;". In the next page traversal, CTabFolder#onPageTraversal(Event) sometimes doesn't find the selected item, because its 'showing' field is still 'false'. - When I revert commit c68f62c9983c4bd3a099b9805f372a1acbf5843f (bug 389773), then I can't reproduce the problem. Problem is probably the asyncExec. It looks like a timing issue, and it's probably easier to reproduce if you enable as many "Link with Editor" views as possible to make editor switching slower (e.g. enable linking in Package Explorer and the History view). There's a standalone snippet that shows the problem:
import org.eclipse.swt.*;
import org.eclipse.swt.custom.*;
import org.eclipse.swt.events.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.widgets.*;
public class CTabFolderBug394016 {
public static void main(String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
shell.setLayout(new FillLayout());
CTabFolder tabFolder = new CTabFolder(shell, SWT.BORDER);
tabFolder.setSimple(false);
tabFolder.setMaximizeVisible(true);
tabFolder.setMinimizeVisible(true);
tabFolder.setMRUVisible(true);
for (int i = 0; i < 12; i++) {
CTabItem item = new CTabItem(tabFolder, SWT.NULL);
item.setText("Tab " + i);
StyledText itemText = new StyledText(tabFolder, SWT.MULTI);
itemText.setText("\n\tText control for tab " + i + "\n\n\n");
item.setControl(itemText);
}
tabFolder.addSelectionListener(new SelectionAdapter() {
@Override
public void widgetSelected(SelectionEvent e) {
try {
Thread.sleep(200);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
});
shell.setSize(300, 100);
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
}
}
The factors are setMRUVisible(true) and a slow SelectionListener. Note that ArrowLeft/Right have the same problems.
Thanks for the snippet, Markus - that really helped. Here's a new fix that updates without async for keyboard events. Released to master: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2eb0d57b46ef2fa0c4a9cfafa527354a559190cd Please test in a build and let me know if you still have any problems. After your ok, I will backport the fix to 4.2 and close this bug. Switching Target to 4.2.2, so we don't forget to backport this. Thanks. I tried hard to break it, but all problems mentioned in this bug are indeed fixed now. I still don't understand why CTabFolder#setSelection(int) sets "selection.showing = false;", but that's been in for 7 years now, so it can't be that bad (and taking it out breaks the rendering of the close button...). Markus, should I close this as FIXED then ?? (In reply to comment #22) > Markus, should I close this as FIXED then ?? Nope, SWT will use this bug to backport to 4.2.2, see comment 20. Sorry, I only now saw that the bug's component was wrongly set to UI. OK, thanks ! Backported to 4.2.2: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_2_maintenance&id=9b82b8c0bd6ac857b43df2639b069d3dea8bdcf7 Verified in M20130116-1800 and master. |