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

Suggestions pop up of the Japanese MS IME got pushed down after multiple commands #13769

Closed
rabianr opened this issue Aug 18, 2022 · 11 comments · Fixed by #13785
Closed

Suggestions pop up of the Japanese MS IME got pushed down after multiple commands #13769

rabianr opened this issue Aug 18, 2022 · 11 comments · Fixed by #13785
Assignees
Labels
Area-Input Related to input processing (key presses, mouse, etc.) 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. Needs-Tag-Fix Doesn't match tag requirements 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.

Comments

@rabianr
Copy link

rabianr commented Aug 18, 2022

Windows Terminal version

1.15.2282.0

Windows build number

10.0.19044.1889

Other Software

No response

Steps to reproduce

  • Entering multiple commands or just press Enter multiple times.
  • Japanese MS IME's suggestions pop up got pushed down gradually.

Expected Behavior

this doesn't happen on v1.13.10983.0
terminal-1 13

what's being typed is shown in the input area
image

Actual Behavior

This happens on v1.14.1432.0 and above.

v1.15.2282.0
terminal-1 15

v1.14.1432.0
terminal-1 14

also, what's being typed isn't shown in the input area
image

@rabianr rabianr added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Aug 18, 2022
@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 Aug 18, 2022
@zadjii-msft
Copy link
Member

oh no, we must have lost a DIP<->Pixel conversion somewhere in #13677 or #13678.

@zadjii-msft zadjii-msft added Area-Input Related to input processing (key presses, mouse, etc.) Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Product-Terminal The new Windows Terminal. Priority-1 A description (P1) labels Aug 18, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Aug 18, 2022
@zadjii-msft zadjii-msft added this to the Terminal v1.16 milestone Aug 18, 2022
@DHowett
Copy link
Member

DHowett commented Aug 18, 2022

We may also (or instead) have mixed up a viewport -> buffer conversion.

@DHowett DHowett self-assigned this Aug 18, 2022
@DHowett
Copy link
Member

DHowett commented Aug 18, 2022

I'm bisecting. :)

git bisect start v1.14.1432.0 29e97b618 src/cascadia
Bisecting: 111 revisions left to test after this (roughly 7 steps)

@DHowett
Copy link
Member

DHowett commented Aug 18, 2022

I may not be able to finish bisecting just yet. Here's the current bisect log:

# bad: [39c71d642179403d52b04a03de7014820ab85657] Debounce window state changes caused by the PTY (#13147)
# good: [29e97b61823297b414c41fc70725569a2acf32cf] Update readme to account for minversion bump (#12332)
git bisect start 'v1.14.1432.0' '29e97b618' 'src/cascadia'
# good: [73f02024d29cf558e42633f93e707631c306bf6f] AtlasEngine: Fix grayscale blending shader (#12734)
git bisect good 73f02024d29cf558e42633f93e707631c306bf6f
# good: [30383ccc2210e3e7d62323421748c6eedf4b5fdd] Revert "Add support for rich code navigation in GitHub (#12855)" (#12909)
git bisect good 30383ccc2210e3e7d62323421748c6eedf4b5fdd

@DHowett
Copy link
Member

DHowett commented Aug 19, 2022

This is weird, but bisect pointed to f4e0d9f (#13024)

It did remove a copy of Terminal::GetCursorPosition that returned the position adjusted by the viewport offset from TerminalApi.cpp.

We may need to introduce something like that again -- or propagate knowledge of the viewport offset up to ControlCore?

(/cc @j4james)

@DHowett
Copy link
Member

DHowett commented Aug 19, 2022

Oh my god, I think we were just getting unimaginably lucky the whole time?

src\cascadia\TerminalCore\TerminalApi.cpp
53:til::point Terminal::GetCursorPosition()

src\cascadia\TerminalCore\terminalrenderdata.cpp
41:COORD Terminal::GetCursorPosition() const noexcept

There were two, and one of them was pulled when we were const-qualified.

James' PR removed the first one.

They had different return values...!

@j4james
Copy link
Collaborator

j4james commented Aug 19, 2022

Sorry about that. I'll try and have a look on the weekend if someone else hasn't fixed it by then.

@zadjii-msft
Copy link
Member

supa-hot-loop-omg

@zadjii-msft zadjii-msft removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Aug 19, 2022
@ghost ghost added the In-PR This issue has a related PR label Aug 19, 2022
DHowett added a commit that referenced this issue Aug 19, 2022
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore.
This has been widely regarded as a good move.

Now, you might rightly be wondering: why didn't compilation immediately
fail? Well. It turns out that there were _two_ copies of
`GetCursorPosition`. One for `const Terminal`, and one for `Terminal`.
This is important.

`Terminal::GetCursorPosition()` returned the cursor position relative to
the viewport. `Terminal::GetCursorPosition() const`, however, returns
the cursor position in absolute.

We removed the non-`const` one. Fortunately, thanks to the lookup rules
for `const`-qualified members, this didn't matter. Code that called
`GetCursorPosition()` still called `GetCursorPosition()`, and everything
was fine.

Except that part about the relative coordinates. That was not fine.

The TSF control is the _only_ consumer of `ControlCore.CursorPosition`,
and that was the _only_ consumer of relative-`GetCursorPosition()`.

This commit restores equilibrium by introducing a new
`GetViewportRelativeCursorPosition()` member to `Terminal` and switching
over the only consumer of relative cursor position to use it.

Closes #13769.
@DHowett
Copy link
Member

DHowett commented Aug 19, 2022

@j4james no worries, I've submitted PR #13785 for it.

DHowett added a commit that referenced this issue Aug 19, 2022
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore.
This has been widely regarded as a good move.

Now, you might rightly be wondering: why didn't compilation immediately
fail? Well. It turns out that there were _two_ copies of
`GetCursorPosition`. One for `const Terminal`, and one for `Terminal`.
This is important.

`Terminal::GetCursorPosition()` returned the cursor position relative to
the viewport. `Terminal::GetCursorPosition() const`, however, returns
the cursor position in absolute.

We removed the non-`const` one. Fortunately, thanks to the lookup rules
for `const`-qualified members, this didn't matter. Code that called
`GetCursorPosition()` still called `GetCursorPosition()`, and everything
was fine.

Except that part about the relative coordinates. That was not fine.

The TSF control is the _only_ consumer of `ControlCore.CursorPosition`,
and that was the _only_ consumer of relative-`GetCursorPosition()`.

This commit restores equilibrium by introducing a new
`GetViewportRelativeCursorPosition()` member to `Terminal` and switching
over the only consumer of relative cursor position to use it.

Closes #13769.
DHowett added a commit that referenced this issue Aug 22, 2022
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore.
This has been widely regarded as a good move.

Now, you might rightly be wondering: why didn't compilation immediately
fail? Well. It turns out that there were _two_ copies of
`GetCursorPosition`. One for `const Terminal`, and one for `Terminal`.
This is important.

`Terminal::GetCursorPosition()` returned the cursor position relative to
the viewport. `Terminal::GetCursorPosition() const`, however, returns
the cursor position in absolute.

We removed the non-`const` one. Fortunately, thanks to the lookup rules
for `const`-qualified members, this didn't matter. Code that called
`GetCursorPosition()` still called `GetCursorPosition()`, and everything
was fine.

Except that part about the relative coordinates. That was not fine.

The TSF control is the _only_ consumer of `ControlCore.CursorPosition`,
and that was the _only_ consumer of relative-`GetCursorPosition()`.

This commit restores equilibrium by introducing a new
`GetViewportRelativeCursorPosition()` member to `Terminal` and switching
over the only consumer of relative cursor position to use it.

Closes #13769.
Backport of #13785.
DHowett added a commit that referenced this issue Aug 22, 2022
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore.
This has been widely regarded as a good move.

Now, you might rightly be wondering: why didn't compilation immediately
fail? Well. It turns out that there were _two_ copies of
`GetCursorPosition`. One for `const Terminal`, and one for `Terminal`.
This is important.

`Terminal::GetCursorPosition()` returned the cursor position relative to
the viewport. `Terminal::GetCursorPosition() const`, however, returns
the cursor position in absolute.

We removed the non-`const` one. Fortunately, thanks to the lookup rules
for `const`-qualified members, this didn't matter. Code that called
`GetCursorPosition()` still called `GetCursorPosition()`, and everything
was fine.

Except that part about the relative coordinates. That was not fine.

The TSF control is the _only_ consumer of `ControlCore.CursorPosition`,
and that was the _only_ consumer of relative-`GetCursorPosition()`.

This commit restores equilibrium by introducing a new
`GetViewportRelativeCursorPosition()` member to `Terminal` and switching
over the only consumer of relative cursor position to use it.

Closes #13769.
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Needs-Tag-Fix Doesn't match tag requirements and removed In-PR This issue has a related PR labels Aug 22, 2022
DHowett added a commit that referenced this issue Sep 6, 2022
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore.
This has been widely regarded as a good move.

Now, you might rightly be wondering: why didn't compilation immediately
fail? Well. It turns out that there were _two_ copies of
`GetCursorPosition`. One for `const Terminal`, and one for `Terminal`.
This is important.

`Terminal::GetCursorPosition()` returned the cursor position relative to
the viewport. `Terminal::GetCursorPosition() const`, however, returns
the cursor position in absolute.

We removed the non-`const` one. Fortunately, thanks to the lookup rules
for `const`-qualified members, this didn't matter. Code that called
`GetCursorPosition()` still called `GetCursorPosition()`, and everything
was fine.

Except that part about the relative coordinates. That was not fine.

The TSF control is the _only_ consumer of `ControlCore.CursorPosition`,
and that was the _only_ consumer of relative-`GetCursorPosition()`.

This commit restores equilibrium by introducing a new
`GetViewportRelativeCursorPosition()` member to `Terminal` and switching
over the only consumer of relative cursor position to use it.

Closes #13769.

(cherry picked from commit 2dedc9a)
Service-Card-Id: 85131461
Service-Version: 1.15
@ghost
Copy link

ghost commented Sep 13, 2022

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

Handy links:

@ghost
Copy link

ghost commented Sep 13, 2022

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

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Input Related to input processing (key presses, mouse, etc.) 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. Needs-Tag-Fix Doesn't match tag requirements 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

Successfully merging a pull request may close this issue.

4 participants