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.

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

Clicking on window without dragging causes a selection #2636

Closed
Molanda opened this issue Sep 2, 2019 · 8 comments
Closed

Clicking on window without dragging causes a selection #2636

Molanda opened this issue Sep 2, 2019 · 8 comments
Labels
Needs-Tag-Fix Doesn't match tag requirements Resolution-By-Design It's supposed to be this way. Sometimes for compatibility reasons.

Comments

@Molanda
Copy link

Molanda commented Sep 2, 2019

Environment

Windows build number: 10.0.18362.295
Windows Terminal version (if applicable): 0.4.2382.0

Steps to reproduce

Click on the terminal window without dragging.

Expected behavior

This should clear any existing selection but not create a new one. This is consistent with other Windows programs which only show a selection when the cursor is dragged.

Actual behavior

A character is selected.

@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 Sep 2, 2019
@DHowett-MSFT
Copy link
Contributor

Today, this is by design. We don't act like other Windows applications that emit text because they have a selection caret, and we don't. We've been talking about the right behavior here for a while, and we decided that in the "default" configuration we'd match the existing console, which does work like this.

We recently added copyOnSelect which, while it does add the eponymous copy-on-select, also suppresses single-character selection (you must click and drag to another cell before selection begins.)

I'm going to mark this one by-design for now. Thanks/sorry!

@DHowett-MSFT DHowett-MSFT added Resolution-By-Design It's supposed to be this way. Sometimes for compatibility reasons. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Sep 3, 2019
@Molanda
Copy link
Author

Molanda commented Sep 3, 2019

Thank you for your response. I understand the current decision, but would like to add some additional details for consideration.

  • Not all application that emit text have a selection caret. The most notable example is the web browser (excluding form fields). If you click on text in a browser, no selection happens unless you also drag. PuTTY is another example where a drag is required to select.
  • If anything, creating a block on click gives the false visual impression that the cursor has been moved.
  • The existing console has the ability to turn off QuickEdit mode.
  • While the behavior matches the existing console, it really offers no value. If someone clicks the window to the front, their next move is extremely unlikely to be to copy the random character that is now selected.

I will try the copy-on-select once released (I have the build from the Microsoft Store).

@garth
Copy link

garth commented Nov 28, 2019

it really offers no value

I could not agree more with this observation. This needs to be an option. eg 'selectOnClick'?

@DHowett-MSFT
Copy link
Contributor

For what it's worth, I agree. Selection is a charged topic, though, as we've well seen.

If you enable copyOnSelect, terminal disables single-character selection. If that's an acceptable compromise, we can leave it at that and evaluate more robust selection settings as we go forward. 😄

@ryanmortier
Copy link

This is such a terrible user experience.

@DHowett-MSFT
Copy link
Contributor

Thanks for your feedback. It's a good thing we fixed it in #5096.

@Molanda
Copy link
Author

Molanda commented Apr 16, 2020

Awesome news!

@ryanmortier
Copy link

This is great news, thanks so much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs-Tag-Fix Doesn't match tag requirements Resolution-By-Design It's supposed to be this way. Sometimes for compatibility reasons.
Projects
None yet
Development

No branches or pull requests

4 participants