starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

keybindings prevTab/nextTab with ctrl+pageup/ctrl+pagedown jumps to unexpected tabs #11349

New Issue
Closed
opened 2026-01-31 02:45:15 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 02:45:15 +00:00
Owner
Copy Link

Originally created by @WilliamKyle on GitHub (Nov 12, 2020).

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Microsoft Windows [版本 10.0.19042.630]

Windows Terminal version (if applicable):
Windows Terminal
版本: 1.4.3141.0

Any other software?

Steps to reproduce

  • Add keybindings in settings
"keybindings":
    [
        { "command": "prevTab", "keys": "ctrl+pageup" },
        { "command": "nextTab", "keys": "ctrl+pagedown" }
    ]

  • Open 3 or more tabs

  • Use ctrl + pageup or ctrl + pagedown, it doesn't jump to pre or next tab

This settings works well in the version before I upgrade it in Microsoft Store, but I don't know what version was.

Expected behavior

ctrl+pageup to the pre tag

ctrl+pagedown to the next tag

Actual behavior

Random jumps

Originally created by @WilliamKyle on GitHub (Nov 12, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd] Microsoft Windows [版本 10.0.19042.630] Windows Terminal version (if applicable): Windows Terminal 版本: 1.4.3141.0 Any other software? ``` # Steps to reproduce <!-- A description of how to trigger this bug. --> * Add keybindings in settings ``` json "keybindings": [ { "command": "prevTab", "keys": "ctrl+pageup" }, { "command": "nextTab", "keys": "ctrl+pagedown" } ] ``` * Open 3 or more tabs * Use `ctrl + pageup` or `ctrl + pagedown`, it doesn't jump to pre or next tab This settings works well in the version before I upgrade it in Microsoft Store, but I don't know what version was. # Expected behavior <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> `ctrl+pageup` to the pre tag `ctrl+pagedown` to the next tag # Actual behavior <!-- What's actually happening? --> Random jumps
claunia commented 2026-01-31 02:45:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 12, 2020):

If you hold ctrl while you're switching tabs, does a little dialog with a list of your open tabs show up? And does that dialog have them listed in "most recently used" order?

What I'm thinking you're seeing is the new tab switcher which defaults to MRU ordering. You can change this back to in-order traversal with "tabSwitcherMode": "inOrder" (or disable it entirely with "tabSwitcherMode": "disabled")

@zadjii-msft commented on GitHub (Nov 12, 2020): If you hold <kbd>ctrl</kbd> while you're switching tabs, does a little dialog with a list of your open tabs show up? And does that dialog have them listed in "most recently used" order? What I'm thinking you're seeing is the new tab switcher which defaults to MRU ordering. You can change this back to in-order traversal with `"tabSwitcherMode": "inOrder"` (or disable it entirely with `"tabSwitcherMode": "disabled"`)
claunia commented 2026-01-31 02:45:16 +00:00
Author
Owner
Copy Link

@WilliamKyle commented on GitHub (Nov 12, 2020):

I configured it with "tabSwitcherMode": "inOrder" or "tabSwitcherMode": "disabled", both not working in 1.4.3141.0.

And I found tabSwitcherMode in https://docs.microsoft.com/en-us/windows/terminal/customize-settings/global-settings, and this is only working in Windows Terminal Preview.

Fortunately useTabSwitcher is working in 1.4.3141.0.
I configured it with "useTabSwitcher": false and get what I expected.

Thanks for your help.

@WilliamKyle commented on GitHub (Nov 12, 2020): I configured it with `"tabSwitcherMode": "inOrder"` or `"tabSwitcherMode": "disabled"`, both not working in 1.4.3141.0. And I found `tabSwitcherMode` in https://docs.microsoft.com/en-us/windows/terminal/customize-settings/global-settings, and this is only working in `Windows Terminal Preview`. Fortunately `useTabSwitcher` is working in 1.4.3141.0. I configured it with `"useTabSwitcher": false` and get what I expected. Thanks for your help.
claunia commented 2026-01-31 02:45:16 +00:00
Author
Owner
Copy Link

@davidchisnall commented on GitHub (Nov 12, 2020):

For anyone else finding this: It has nothing to do with the key bindings used, the nextTab and prevTab commands are completely broken unless you disable the tab switcher (at least, in v1.5.3142.0). The tab switcher was annoying when it was first introduced (why do I want a UI to pop up listing tabs right next to another UI element that lists tabs?) and probably should default to off. It definitely should not default to a behaviour that breaks tab switching. MRU policies on frequently used UI elements are bad practice in general because they break motor memory.

@davidchisnall commented on GitHub (Nov 12, 2020): For anyone else finding this: It has nothing to do with the key bindings used, the nextTab and prevTab commands are completely broken unless you disable the tab switcher (at least, in v1.5.3142.0). The tab switcher was annoying when it was first introduced (why do I want a UI to pop up listing tabs right next to another UI element that lists tabs?) and probably should default to off. It definitely should not default to a behaviour that breaks tab switching. MRU policies on frequently used UI elements are bad practice in general because they break motor memory.
claunia commented 2026-01-31 02:45:17 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 12, 2020):

MRU policies on frequently used UI elements are bad practice in general because they break motor memory.

alt+tab would like to have a word with you

@zadjii-msft commented on GitHub (Nov 12, 2020): > MRU policies on frequently used UI elements are bad practice in general because they break motor memory. <kbd>alt+tab</kbd> would like to have a word with you
claunia commented 2026-01-31 02:45:17 +00:00
Author
Owner
Copy Link

@davidchisnall commented on GitHub (Nov 12, 2020):

There's been a lot of research covering alt-tab and related things for task switching over the last 30 years. This has led to things like Expose on the Mac and the Tasks View on Windows, which give a stable spatial view that generally do better in user studies than the alt-tab LRU policy, which works well if you are switching between two applications and increasingly badly as that number grows above two.

@davidchisnall commented on GitHub (Nov 12, 2020): There's been a lot of research covering alt-tab and related things for task switching over the last 30 years. This has led to things like Expose on the Mac and the Tasks View on Windows, which give a stable spatial view that generally do better in user studies than the alt-tab LRU policy, which works well if you are switching between two applications and increasingly badly as that number grows above two.
claunia commented 2026-01-31 02:45:17 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 12, 2020):

I'm not gonna disagree with you - I'm an inOrder guy myself. But my dedication is to customizability. For everyone out there who likes inOrder traversal, there's someone else who prefers mru, which is why there are settings to enable both modes. It's IMPOSSIBLE to pick a set of defaults that makes everyone happy, but the goal with the Terminal has always been to enable the user to customize it just the way they like it.

Since OP figured this out, I'm gonna close this issue.

@zadjii-msft commented on GitHub (Nov 12, 2020): I'm not gonna disagree with you - I'm an `inOrder` guy myself. But my dedication is to customizability. For everyone out there who likes `inOrder` traversal, there's someone else who prefers `mru`, which is why there are settings to enable both modes. It's IMPOSSIBLE to pick a set of defaults that makes everyone happy, but the goal with the Terminal has always been to enable the user to customize it _just the way they like it_. Since OP figured this out, I'm gonna close this issue.
claunia commented 2026-01-31 02:45:17 +00:00
Author
Owner
Copy Link

@davidchisnall commented on GitHub (Nov 12, 2020):

I don't mind the option of MRU existing, I object to the POLA violation: the meaning of nextTab and prevTab changed during an update and users need to explicitly opt in to the prior behaviour. The new behaviour is significantly worse because the MRU list is update on every switch, so in a four-tab window you will have one tab that is unreachable using the keyboard shortcuts (this was the symptom that I saw that led me to this bug).

@davidchisnall commented on GitHub (Nov 12, 2020): I don't mind the option of MRU existing, I object to the POLA violation: the meaning of nextTab and prevTab changed during an update and users need to explicitly opt in to the prior behaviour. The new behaviour is significantly worse because the MRU list is update on every switch, so in a four-tab window you will have one tab that is unreachable using the keyboard shortcuts (this was the symptom that I saw that led me to this bug).
claunia commented 2026-01-31 02:45:17 +00:00
Author
Owner
Copy Link

@zachjweiner commented on GitHub (Nov 12, 2020):

FWIW, I was about to post an issue that "tabSwitcherMode": "inOrder" does not override the change in default introduced in 1.4.3141.0. (It seems this setting isn't supposed to be respected in 1.4, though?)

So the new tab switcher suddenly only works in MRU mode, and the previous default cannot be restored without disabling the interface entirely. I would think this is a regression, but please let me know if I'm missing something.

@zachjweiner commented on GitHub (Nov 12, 2020): FWIW, I was about to post an issue that `"tabSwitcherMode": "inOrder"` does not override the change in default introduced in 1.4.3141.0. (It seems this setting isn't supposed to be respected in 1.4, though?) So the new tab switcher suddenly only works in MRU mode, and the previous default cannot be restored without disabling the interface entirely. I would think this is a regression, but please let me know if I'm missing something.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Question Needs-Attention Needs-Tag-Fix Needs-Triage Resolution-Answered
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11349
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?