starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 16:34:42 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Behaviour of click-and-drag text selection depends inconsistently on prior pane and application focus state #6018

New Issue
Closed
opened 2026-01-31 00:27:57 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 00:27:57 +00:00
Owner
Copy Link

Originally created by @0xabu on GitHub (Jan 17, 2020).

Originally assigned to: @leonMSFT on GitHub.

Environment

Windows build number: 10.0.18363.592
Windows Terminal version: 0.8.10091.0

NB: I have copy-on-select enabled, although I suspect it doesn't matter.

Steps to reproduce

  1. Open a tab with one pane.
  2. Remove focus from windows terminal (i.e. focus another app).
  3. Click and drag to select some text in the terminal. Notice that this first click focused the window, but didn't select anything.
  4. Click and drag again to select some text in the terminal. Now the text is selected.

The need for step 4 isn't ideal (other apps don't work this way), but it is reasonably intuitive and easy to recover from. But let's see what happens when we have two panes open and we try to select the "wrong" one:

  1. Open a second pane in the same tab.
  2. Remove focus from the terminal. Notice how one pane stays selected/"focused" even if the window as a whole lacks focus.
  3. Click and drag to select some text in the terminal in the original (deselected) pane. Like the single-pane case, the first click focused the terminal window, but nothing else happened.
  4. Click and drag again in the deselected pane. Still nothing happens.
  5. Get annoyed, single click the pane to focus it, then select the text you wanted.

I've also noticed that, once an unfocused pane has a selection, clicking and dragging in that pane seems to ignore the click point (perhaps it never gets the click event?) and treat the drag as a continuation of the prior selection.

Expected behavior

I should be able to select text by clicking and dragging over it:

  • regardless of the prior focus state of the pane I'm selecting in
  • regardless of the prior focus state of the terminal window
  • regardless of what was previously selected (i.e. a new click-drag should always start a new selection)

Actual behavior

Described above.

The fact that each pane has its own selection (so you can select text concurrently in multiple panes) might be a useful feature, but it seems to cause a lot of strange inconsistencies with text selection and copy/paste.

Originally created by @0xabu on GitHub (Jan 17, 2020). Originally assigned to: @leonMSFT on GitHub. # Environment ```none Windows build number: 10.0.18363.592 Windows Terminal version: 0.8.10091.0 ``` NB: I have copy-on-select enabled, although I suspect it doesn't matter. # Steps to reproduce 1. Open a tab with one pane. 2. Remove focus from windows terminal (i.e. focus another app). 3. Click and drag to select some text in the terminal. Notice that this first click focused the window, but didn't select anything. 4. Click and drag again to select some text in the terminal. Now the text is selected. The need for step 4 isn't ideal (other apps don't work this way), but it is reasonably intuitive and easy to recover from. But let's see what happens when we have two panes open and we try to select the "wrong" one: 1. Open a second pane in the same tab. 2. Remove focus from the terminal. Notice how one pane stays selected/"focused" even if the window as a whole lacks focus. 3. Click and drag to select some text in the terminal *in the original (deselected) pane*. Like the single-pane case, the first click focused the terminal window, but nothing else happened. 4. Click and drag again in the deselected pane. Still nothing happens. 5. Get annoyed, single click the pane to focus it, then select the text you wanted. I've also noticed that, once an unfocused pane has a selection, clicking and dragging in that pane seems to ignore the click point (perhaps it never gets the click event?) and treat the drag as a continuation of the prior selection. # Expected behavior I should be able to select text by clicking and dragging over it: * regardless of the prior focus state of the pane I'm selecting in * regardless of the prior focus state of the terminal window * regardless of what was previously selected (i.e. a new click-drag should always start a new selection) # Actual behavior Described above. The fact that each pane has its own selection (so you can select text concurrently in multiple panes) might be a useful feature, but it seems to cause a lot of strange inconsistencies with text selection and copy/paste.
claunia commented 2026-01-31 00:27:58 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 23, 2020):

Yeah, this is definitely something that we should fix. Thanks for the comprehensive report!

@carlos-zamora I was talking about the issues with beginning/ending selections on things that are/are not focused, and how we need to comport that with "don't select a single cell when the user brings the terminal window to the front by clicking inside it."

Can you find the duplicates here?

@DHowett-MSFT commented on GitHub (Jan 23, 2020): Yeah, this is definitely something that we should fix. Thanks for the comprehensive report! @carlos-zamora I was talking about the issues with beginning/ending selections on things that are/are not focused, and how we need to comport that with "don't select a single cell when the user brings the terminal window to the front by clicking inside it." Can you find the duplicates here?
claunia commented 2026-01-31 00:27:58 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Jan 28, 2020):

#1038 and #1367 are probably related to this. Just connecting a general set of issues related to focus and selection in the terminal control.

@carlos-zamora commented on GitHub (Jan 28, 2020): #1038 and #1367 are probably related to this. Just connecting a general set of issues related to focus and selection in the terminal control.
claunia commented 2026-01-31 00:27:58 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Feb 13, 2020):

:tada:This issue was addressed in #4506, which has now been successfully released as Windows Terminal Preview v0.9.433.0.🎉

Handy links:

@ghost commented on GitHub (Feb 13, 2020): :tada:This issue was addressed in #4506, which has now been successfully released as `Windows Terminal Preview v0.9.433.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.9.433.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
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 Area-TerminalControl Issue-Bug Priority-3 Product-Terminal Resolution-Fix-Committed
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#6018
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?