Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The nextTab and prevTab actions do not work correctly when initiated via wt.exe or the command palette #10070

Closed
gurnec opened this issue May 10, 2021 · 4 comments · Fixed by #10947
Closed

The nextTab and prevTab actions do not work correctly when initiated via wt.exe or the command palette #10070

gurnec opened this issue May 10, 2021 · 4 comments · Fixed by #10947
Assignees
@leonMSFT
Labels
Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Terminal v2.0

Comments

@gurnec
Copy link

gurnec commented May 10, 2021 •
edited
Loading

In short, wt focus-tab --next and --previous don't do anything at all on my system, while Next tab and Previous tab via the command palette behave oddly, although I can't imagine that the latter is often used by anyone.

Windows Terminal version (or Windows build number)

1.8.1032.0

Steps to reproduce

Case 1:

Run wt -w new new-tab ; new-tab ; focus-tab --next (or --previous).

Case 2:

Run wt -w new new-tab ; new-tab.

In the new window, run wt -w 0 focus-tab --next (or --previous).

Case 3:

Run wt -w new new-tab ; new-tab ; new-tab.

In the new window, open the command palette (by default using Ctrl+Shift+P) and type in Next tab (or Previous tab) Enter.

Expected Behavior

Case 1:

The first tab is focused.

Case 2:

The first tab is focused.

Case 3:

The desired tab (according to the tabSwitcherMode) is focused.

Actual Behavior

Case 1:

The focus-tab subcommand is ignored; the second tab remains focused.

Case 2:

The focus-tab subcommand is ignored; the second tab remains focused.

Note that in the two cases above, wt focus-tab --target 0 works correctly.

Case 3:

This depends on the tabSwitcherMode:

  • mru — the desired tab is focused for a split second, and then the originally-focused tab regains focus.
  • inOrder — the desired tab is focused for a split second, and then tab index 0 gains focus.
  • disabled — the desired tab is focused (there is no bug in this case).

My apologies if I should have separated this into two issues.

Thanks!
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels May 10, 2021
@zadjii-msft
Copy link
Member

Huh. That's certainly weird. I bet we're using the MRU order for --next and --previous, but that's almost certainly not getting updated during the initial processing of commandline actions. Great catch!

@zadjii-msft zadjii-msft added Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. labels May 11, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 11, 2021
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone May 11, 2021
@zadjii-msft zadjii-msft mentioned this issue May 11, 2021
Open
40 tasks
@DHowett DHowett removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label May 13, 2021
@DHowett
Copy link
Member

DHowett commented May 13, 2021

Discussion during triage: We probably shouldn't even be using MRU during focus-tab.

@leonMSFT leonMSFT self-assigned this May 14, 2021
@Don-Vito
Copy link
Contributor

Yeah, MRU during startup makes little sense. I will issue a PR (it is few lines of code). However, I thought we need to update this in documentation and found no documentation for these flags. Am I missing something?

@Don-Vito Don-Vito mentioned this issue Aug 15, 2021
Merged
@ghost ghost added the In-PR This issue has a related PR label Aug 15, 2021
DHowett pushed a commit that referenced this issue Aug 19, 2021
@Don-Vito
Fix focus-tab --previous/next to ignore tab switcher order (#10947)
46fd7ca 
When creating `startupAction` use `TabSwitcherMode::Disabled` in action args
to disable the tab switcher and prevent MRU logic to be applied.

Closes #10070
@ghost ghost added Needs-Tag-Fix Doesn't match tag requirements Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Aug 19, 2021
@ghost
Copy link

ghost commented Aug 31, 2021

🎉This issue was addressed in #10947, which has now been successfully released as Windows Terminal Preview v1.11.2421.0.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@leonMSFT leonMSFT

Labels
Area-Commandline wt.exe's commandline arguments Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Priority-2 A description (P2) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Milestone
Terminal v2.0
Development

Successfully merging a pull request may close this issue.

Fix focus-tab --previous/next to ignore tab switcher order Don-Vito/terminal
5 participants
@DHowett @gurnec @Don-Vito @zadjii-msft @leonMSFT