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

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

Closed
0xabu opened this issue Jan 17, 2020 · 3 comments · Fixed by #4506
Closed

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

0xabu opened this issue Jan 17, 2020 · 3 comments · Fixed by #4506
Assignees
@leonMSFT
Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) 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 v1.0

Comments

@0xabu
Copy link

0xabu commented Jan 17, 2020

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.
@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 Jan 17, 2020
@DHowett-MSFT
Copy link
Contributor

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 DHowett-MSFT added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Jan 23, 2020
@carlos-zamora
Copy link
Member

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

This was referenced Jan 28, 2020
Closed
Closed
@carlos-zamora carlos-zamora added Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal. v1-Scrubbed and removed Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Tag-Fix Doesn't match tag requirements labels Jan 29, 2020
@carlos-zamora carlos-zamora added this to the Terminal v1.0 milestone Jan 29, 2020
@leonMSFT leonMSFT mentioned this issue Feb 7, 2020
Merged
3 tasks
@ghost ghost added the In-PR This issue has a related PR label Feb 7, 2020
@ghost ghost closed this as completed in #4506 Feb 13, 2020
ghost pushed a commit that referenced this issue Feb 13, 2020
@leonMSFT
Fix click-drag selection on an unfocused Terminal (#4506)
7836da0 
## Summary of the Pull Request
This PR tries to address some of the weird interactions with pointer pressed events when the Terminal isn't in focus. Here's the four things that have changed as part of this PR;

1. This PR will allow the user to be able to make a selection with a click-drag without having to first perform a single click on a tab/pane to bring it to focus. 
2. Another weird bug that's fixed in this PR is where trying to make a selection on an unfocused tab when it already has a selection active will simply extend the existing selection instead of making a new one.
3. Not related to the issue that his PR closes: a right click will now focus the tab/pane.

I've made sure that we still have the existing functionality where a single click on an unfocused tab/pane does not make a single-cell selection and just focuses the tab/pane.

## PR Checklist
* [x] Closes #4282
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed

## Validation Steps Performed
Played around with all sorts of selection when in-focus and out of focus with multiple panes and tabs.
Unit tests still pass as well.
@ghost ghost added 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 Feb 13, 2020
@ghost
Copy link

ghost commented Feb 13, 2020

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

Handy links:

DHowett-MSFT pushed a commit that referenced this issue Mar 24, 2020
@DHowett
Rework and simplify selection in TermControl
53080d3 
This commit rewrites selection handling at the TermControl layer.
Previously, we were keeping track of a number of redundant variables
that were easy to get out of sync.

The new selection model is as follows:

* A single left click will always begin a _pending_ selection operation
* A single left click will always clear a selection (#4477)
* A double left click will always begin a word selection
* A triple left click will always begin a line selection
* A selection will only truly start when the cursor moves a quarter of
  the smallest dimension of a cell (usually its width) in any direction
  _This eliminates the selection of a single cell on one click._
  (#4282, #5082)
* We now keep track of whether the selection has been "copied", or
  "updated" since it was last copied. If an endpoint moves, it is
  updated. For copy-on-select, it is only copied if it's updated.
  (#4740)

Because of this, we can stop tracking the position of the focus-raising
click, and whether it was part of click-drag operation. All clicks can
_become_ part of a click-drag operation if the user drags.

We can also eliminate the special handling of single cell selection at
the TerminalCore layer: since TermControl determines when to begin a
selection, TerminalCore no longer needs to know whether copy on select
is enabled _or_ whether the user has started and then backtracked over a
single cell. This is now implicit in TermControl.

Fixes #4082; Fixes #4477
@DHowett-MSFT DHowett-MSFT mentioned this issue Mar 24, 2020
Merged
ghost pushed a commit that referenced this issue Mar 25, 2020
@DHowett
Rework and simplify selection in TermControl (#5096)
499f24a 
This commit rewrites selection handling at the TermControl layer.
Previously, we were keeping track of a number of redundant variables
that were easy to get out of sync.

The new selection model is as follows:

* A single left click will always begin a _pending_ selection operation
* A single left click will always clear a selection (#4477)
* A double left click will always begin a word selection
* A triple left click will always begin a line selection
* A selection will only truly start when the cursor moves a quarter of
  the smallest dimension of a cell (usually its width) in any direction
  _This eliminates the selection of a single cell on one click._
  (#4282, #5082)
* We now keep track of whether the selection has been "copied", or
  "updated" since it was last copied. If an endpoint moves, it is
  updated. For copy-on-select, it is only copied if it's updated.
  (#4740)

Because of this, we can stop tracking the position of the focus-raising
click, and whether it was part of click-drag operation. All clicks can
_become_ part of a click-drag operation if the user drags.

We can also eliminate the special handling of single cell selection at
the TerminalCore layer: since TermControl determines when to begin a
selection, TerminalCore no longer needs to know whether copy on select
is enabled _or_ whether the user has started and then backtracked over a
single cell. This is now implicit in TermControl.

Fixes #5082; Fixes #4477
@zadjii-msft zadjii-msft mentioned this issue Apr 28, 2020
Closed
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@leonMSFT leonMSFT

Labels
Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) 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 v1.0
Development

Successfully merging a pull request may close this issue.

Fix click-drag selection on an unfocused Terminal microsoft/terminal
4 participants
@carlos-zamora @0xabu @DHowett-MSFT @leonMSFT