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

ConPTY: Flush unhandled sequences to the buffer #17741

Merged
merged 9 commits into from
Aug 22, 2024

Conversation

lhecker
Copy link
Member

@lhecker lhecker commented Aug 19, 2024

#17510 made it so that VT requests like DA1 are passed through to the
hosting terminal and so conhost stopped responding to them on its own.
But since our input parser doesn't support proper passthrough (yet),
it swallowed the response coming from the terminal.

To solve this issue, this PR repurposes the existing boolean return
values to indicate to the parser whether the current sequence should
be flushed to the dispatcher as-is. The output parser always returns
true (success) and leaves its pass-through handler empty, while the
input parser returns false for sequences it doesn't expect.

Validation Steps Performed

  • Launch cmd
  • Press Ctrl+[, [, c, Enter (= ^[[c = DA1 request)
  • DA1 response is visible ✅

@lhecker lhecker added Product-Conpty For console issues specifically related to conpty Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) labels Aug 19, 2024
Comment on lines +2163 to +2166
if (!ok)
{
FlushToTerminal();
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the important bit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we flush it even if it made us throw an exception?

Copy link
Member Author

@lhecker lhecker Aug 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's an edge case that's not too important, at least initially. There shouldn't be any exceptions unless it's an OOM or similar exceptional issue. Failure to parse a sequence should never raise an exception IMO.

Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Largely mechanical, but this does change how passed-through VT input is encoded (from only keydown events with no scancode to full key events as though a human typed them on a keyboard), and I want to know whether that's scary.

You also got rid of most of the users of RETURN_BOOL_IF_FALSE, which is a macro of our own creation. Want to go the rest of the way and kill it, too?

src/terminal/adapter/InteractDispatch.cpp Outdated Show resolved Hide resolved
src/terminal/parser/InputStateMachineEngine.cpp Outdated Show resolved Hide resolved
Comment on lines +2163 to +2166
if (!ok)
{
FlushToTerminal();
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we flush it even if it made us throw an exception?

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 20, 2024
@DHowett
Copy link
Member

DHowett commented Aug 20, 2024

(I'd love to see a bit more validation on WSL as well, and I suspect @j4james will have some feelings about this! I'm in favor of the architectural shift.)

@microsoft-github-policy-service microsoft-github-policy-service bot removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 20, 2024
Copy link
Collaborator

@j4james j4james left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still need to look at the InputStateMachine. Just wanted to get the return value refactoring out of the way first. Btw, I'm very happy with this change - I was actually about to propose doing it myself.

src/terminal/adapter/ut_adapter/adapterTest.cpp Outdated Show resolved Hide resolved
src/terminal/adapter/ut_adapter/adapterTest.cpp Outdated Show resolved Hide resolved
src/terminal/adapter/ut_adapter/adapterTest.cpp Outdated Show resolved Hide resolved
src/terminal/adapter/ut_adapter/adapterTest.cpp Outdated Show resolved Hide resolved
src/terminal/adapter/ut_adapter/adapterTest.cpp Outdated Show resolved Hide resolved
src/terminal/adapter/adaptDispatch.cpp Outdated Show resolved Hide resolved
src/terminal/adapter/adaptDispatch.cpp Outdated Show resolved Hide resolved
src/terminal/adapter/adaptDispatch.cpp Outdated Show resolved Hide resolved
src/terminal/parser/OutputStateMachineEngine.cpp Outdated Show resolved Hide resolved
src/terminal/parser/OutputStateMachineEngine.cpp Outdated Show resolved Hide resolved
@lhecker
Copy link
Member Author

lhecker commented Aug 20, 2024

Thank you so much for the exhaustive review @j4james!

@lhecker
Copy link
Member Author

lhecker commented Aug 20, 2024

Largely mechanical, but this does change how passed-through VT input is encoded (from only keydown events with no scancode to full key events as though a human typed them on a keyboard), and I want to know whether that's scary.

FYI I reverted that bit.

You also got rid of most of the users of RETURN_BOOL_IF_FALSE, which is a macro of our own creation. Want to go the rest of the way and kill it, too?

(I'd love to see a bit more validation on WSL as well, and I suspect j4james will have some feelings about this! I'm in favor of the architectural shift.)

I'm still somewhat squirmish about the change, as the bool returns were used in tests. On the other hand, I feel like there's better ways to test our parser than via bool returns (e.g. by testing side effects).

I've tried reproducing any issues under WSL and couldn't find anything immediately obvious. It seemed fine with various key combinations and in vttest.

Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's go wild. We're already blowing up the world by removing conpty, so let's just go all-in.

@j4james
Copy link
Collaborator

j4james commented Aug 20, 2024

I've been doing some testing of this branch, and there are still a bunch of queries that don't seem to work at the cmd prompt which previously used to work

  • echo ^[[6n (should return a CPR report, but now generates an F3 key press instead)
  • echo ^[[=c (should return a DA3 report like ^[P!|00000000^[\, but we now just get P!|\).
  • echo ^[[18t (should return a size report like ^[[8;24;80t, but we now get nothing).

There are many more, but I think they are all just variations of the above 3 cases.

I'm also now seeing some issues with reports in a WSL shell, which I'm almost sure were working before. I think it's all just DCS reports. For example, printf "\e[=c"; read should produce a report like ^[P!|00000000^[\, but now we get something like ^[P!|^[P!|00000000^[\.

@lhecker
Copy link
Member Author

lhecker commented Aug 21, 2024

echo ^[[6n: I solved this by checking for _encounteredWin32InputModeSequence. I'm not sure if there's a better alternative, except for tracking DSR in the output parser. That seemed like a heuristic to me that's just as bad, since input/output run concurrent to each other.

echo ^[[=c: In cmd, this parses into 0 parameters and runs into ActionEscDispatch and so it gets treated completely incorrectly. I don't understand why that happens.

@@ -452,9 +458,6 @@ bool InputStateMachineEngine::ActionCsiDispatch(const VTID id, const VTParameter
case CsiActionCodes::CursorBackTab:
_WriteSingleKey(VK_TAB, SHIFT_PRESSED);
return true;
case CsiActionCodes::DTTERM_WindowManipulation:
_pDispatch->WindowManipulation(parameters.at(0), parameters.at(1), parameters.at(2));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean we can unimplement InteractDispatch::WindowManipulation as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's still used in OutputStateMachineEngine isn't it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but that goes through adaptDispatch.

The one from ISM goes through InteractDispatch.

And upon looking at InteractDispatch::WindowManipulation, I fear that we actually might be using it (window manipulation) to help conpty's window transition through states ......

@zadjii-msft zadjii-msft added this to the Terminal v1.22 milestone Aug 22, 2024
Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is really just like 6 lines of meat and 1200 lines of meh

@@ -728,14 +726,14 @@ void StateMachine::_ActionDcsDispatch(const wchar_t wch)

const auto success = _SafeExecute([=]() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this lambda, combined with "the important bit" below, is like, the actual PR here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I apologize for the complete mess of this PR. ☹️
Initially I thought this would be easy, but then the sunken cost fallacy hit me. ☹️☹️

@DHowett DHowett merged commit 6dd9c46 into main Aug 22, 2024
20 checks passed
@DHowett DHowett deleted the dev/lhecker/conpty-input-flush-unhandled branch August 22, 2024 22:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Conpty For console issues specifically related to conpty
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants