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

Fix flipped sense in TerminalDispatch::CursorPosition #4113

Merged
merged 1 commit into from
Jan 6, 2020

Conversation

DHowett-MSFT
Copy link
Contributor

Fixes #4107.

@DHowett-MSFT
Copy link
Contributor Author

(thanks @j4james)

I chose to flip the sense here instead of rewriting the function. Options include...

bool success = SUCCEEDED(x) && SUCCEEDED(y);

if (success)
{
    success = SUCCEEDED(a) && ...
}

if (success)

and

THROW_IF_FAILED();
THROW_IF_FAILED();
THROW_IF_FAILED();

(this works because we have a CATCH_RETURN_FALSE)

@j4james
Copy link
Collaborator

j4james commented Jan 5, 2020

I was going to say you actually shouldn't even need those SizeTToShort checks, because a VT parameter can never be greater than a short (it should be clamped by the state machine), but I see now that PR #3956 changed that behaviour. So instead of being pointless, these checks are now also wrong.

If a parameter is greater than a short, it should be clamped rather failing, i.e. you should be able to use a sequence like \e[1;999999H to move to the top right corner of the screen. That used to work, but doesn't anymore.

And note that CUP won't be the only operation broken by that change (some may even crash the conhost). Either they all need to add their own parameter clamping code, or we should add the clamping back in the state machine (which would be my preference). That said, it's probably best to get this particular fix merged ASAP and worry about the clamping in a followup issue.

@lhecker
Copy link
Member

lhecker commented Jan 5, 2020

Ah dammit I was about to submit a PR myself after debugging this issue today. 😣
(In fact PowerShell was broken entirely due to this change. It returns cursor position sequences on each input!)

I agree with @j4james that values should be capped because such a lenient behavior is probably what you'd want anyways. From a cursory glance SetCursorPosition seems to be robust against negative values too. For instance this is what I'd personally imagine for this PR:

bool TerminalDispatch::CursorPosition(const size_t line,
                                      const size_t column) noexcept
{
    const auto clamp = [](const size_t val) noexcept -> short {
        constexpr size_t min = 1;
        constexpr size_t max = std::numeric_limits<short>::max();
        return static_cast<short>(std::clamp(val, min, max) - min);
    };

    return _terminalApi.SetCursorPosition(clamp(column), clamp(line));
}

(It's certainly not beautiful code, so please feel free to use it. 😄 A wrapper class with saturating arithmetic would surely be helpful here in the future.)

@j4james
Copy link
Collaborator

j4james commented Jan 5, 2020

@lhecker Note that the CursorPosition method is just one example of the clamping problem. We're going to have the same issue in many other operations.

A wrapper class with saturating arithmetic would surely be helpful here in the future.)

Yeah, that's being discussed in #4013. In the sort term, though, adding the clamping back in the state machine would at least solve a lot of the problems.

@zadjii-msft
Copy link
Member

@j4james @lhecker those are both good suggestions, though I think I'd probably want to get this fix merged in ASAP, since the Terminal's pretty horribly broken without it. I'd probably just file a follow up with those suggestions personally, though I'd be curious to hear @DHowett-MSFT's thoughts on the matter.

@zadjii-msft zadjii-msft added the Needs-Second It's a PR that needs another sign-off label Jan 6, 2020
@ghost ghost requested a review from carlos-zamora January 6, 2020 12:44
@zadjii-msft zadjii-msft modified the milestone: Terminal-2001 Jan 6, 2020
@miniksa
Copy link
Member

miniksa commented Jan 6, 2020

We'll talk about prioritizing #4013 for this week since it's becoming a problem and will support other work.

@DHowett-MSFT DHowett-MSFT merged commit 4882917 into master Jan 6, 2020
@DHowett-MSFT DHowett-MSFT deleted the dev/duhowett/4107 branch January 6, 2020 22:45
@DHowett-MSFT
Copy link
Contributor Author

We'll likely end up doing 4013 this week.

@DHowett-MSFT
Copy link
Contributor Author

This is an unblocker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs-Second It's a PR that needs another sign-off
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Some newlines appear to be broken
6 participants