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

System's Text Cursor Indicator is ignored on new tab and also moving its window using only keyboard and GuiThreadInfo's GetCaretPos doesn't return its caret position #6805

Closed
vhanla opened this issue Jul 6, 2020 · 3 comments
Labels
Area-Accessibility Issues related to accessibility 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-1 A description (P1) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@vhanla
Copy link

vhanla commented Jul 6, 2020

Environment

Windows build number: Microsoft Windows [Versión 10.0.19041.329]
Windows Terminal version (if applicable): 1.0.1811.0

Any other software?

Steps to reproduce

Enable Windows's Text Cursor Indicator in Control Panel.
imagen

1st scenario.

Open a new TAB, then you will notice that the Text Cursor Indicator is not working anymore.
cursor issue 01b

2nd scenario.

Move current Windows Terminal window using only keyboard as following:
Press Alt+Space select Move menu item then move it using the arrow keys.
Now the Text Cursor Indicator stops following your typing cursor position.
imagen
imagen

3rd scenario.

Use Winapi using GetGUIThreadInfo combined with GetCaretPos, to ge curret window's caret position.
Or just use the demo project from https://www.codeproject.com/articles/34520/getting-caret-position-inside-any-application
It works even CMD and PowerShell, but not in Windows Terminal.

Expected behavior

Keep tracking the text cursor indicator, without using workarounds to restore it as mentioned below.

And for the GetCaretPos issue, it should return the caret poition for third party tools, not only system's Text Cursor Indicator.

Actual behavior

Text cursor indicator is ignored after those steps, and needs other steps to restore th cursor indicator tracker.

NOTICE To restore Text Cursor Indicator is possible by switching back and forth wih Alt+Tab or switching among tabs.

About the GetCaretPos issue, I wrote a tool to highlight the caret position for teaching purposes, specially to attract attention towards the caret position, it even follows the caret position.
imagen
Since GetCaretPos offers that opportunity to achieve that, it is a convenient way for tools like this to help users for whatever reasons they want, like the tool in the picture above, which is working perfectly in the cmd console shell, notepad, powershell's, etc.
However, on Windows Terminal (and Visual Studio Code too) GetCaretPos doesn't work as expected.

I reported this issues since they seem related in someway.

@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 Jul 6, 2020
@vhanla vhanla changed the title System's Text Cursor Indicator is ignored on new tab and also moving its window using only keyboard and GuiThreInfo's GetCaretPos doesn't return its caret position System's Text Cursor Indicator is ignored on new tab and also moving its window using only keyboard and GuiThreaInfo's GetCaretPos doesn't return its caret position Jul 6, 2020
@vhanla vhanla changed the title System's Text Cursor Indicator is ignored on new tab and also moving its window using only keyboard and GuiThreaInfo's GetCaretPos doesn't return its caret position System's Text Cursor Indicator is ignored on new tab and also moving its window using only keyboard and GuiThreadInfo's GetCaretPos doesn't return its caret position Jul 6, 2020
@zadjii-msft
Copy link
Member

These are some good reports! I thought at first that this might have been #3791, but it looks like this is actually it's own new thing. Clearly, there's something else we missed here 😅

@zadjii-msft zadjii-msft added Area-Accessibility Issues related to accessibility 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. Product-Terminal The new Windows Terminal. labels Jul 7, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jul 7, 2020
@zadjii-msft zadjii-msft added the Priority-1 A description (P1) label Jul 7, 2020
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Jul 7, 2020
@DHowett
Copy link
Member

DHowett commented Jul 8, 2020

Hmmm.. yes, this should definitely be fixed.

@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 Jul 8, 2020
@zadjii-msft zadjii-msft modified the milestones: Terminal v2.0, 22H1 Jan 4, 2022
@zadjii-msft
Copy link
Member

Hey guess what, this was actually fixed in #12210, which should be in 1.13

@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Jan 31, 2022
@zadjii-msft zadjii-msft added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed Needs-Tag-Fix Doesn't match tag requirements labels Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Accessibility Issues related to accessibility 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-1 A description (P1) 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
Development

No branches or pull requests

3 participants