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

Output should not keep scrolling down when manually scrolled up #7222

Closed
sozercan opened this issue Aug 7, 2020 · 5 comments · Fixed by #7247
Closed

Output should not keep scrolling down when manually scrolled up #7222

sozercan opened this issue Aug 7, 2020 · 5 comments · Fixed by #7247
Assignees
Labels
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-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) 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

@sozercan
Copy link
Member

sozercan commented Aug 7, 2020

Description of the new feature/enhancement

For example, when tailing/following a log, and cursor is at the bottom. I expect the output to be scrolled down automatically.

However, if I manually scroll up to certain spot (e.g., looking at a test failure), I don't want my current view keep getting scrolled down. It should lock in place when user manually scrolls up. When user scrolls all the way to the bottom, then it should resume tailing.

@sozercan sozercan added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Aug 7, 2020
@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 7, 2020
@50Wliu
Copy link
Member

50Wliu commented Aug 8, 2020

It sounds like this was fixed in 1.2 Preview? #6062 (comment)

@sozercan
Copy link
Member Author

This is still happening for me in 1.2.2022.0. Even when text is selected (didn't realize that was a requirement).

@zadjii-msft
Copy link
Member

Is the entire buffer history full already? It seems like we don't stick the viewport to the right place when text is output and the buffer is already full, causing text circling.

@zadjii-msft zadjii-msft added 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-2 A description (P2) Product-Terminal The new Windows Terminal. and removed Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. labels Aug 11, 2020
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Aug 11, 2020
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Aug 11, 2020
@zadjii-msft zadjii-msft self-assigned this Aug 11, 2020
@ghost ghost added the In-PR This issue has a related PR label Aug 11, 2020
@ghost ghost closed this as completed in #7247 Aug 11, 2020
@ghost ghost removed the In-PR This issue has a related PR label Aug 11, 2020
ghost pushed a commit that referenced this issue Aug 11, 2020
)

If you scroll up to view the scrollback, then we want the viewport to
"stay in place", as new output comes in (see #6062). This works fine up
until the buffer circles. In this case, the mutable viewport isn't
actually moving, so we never set `updatedViewport` to true. 

This regressed in #6062
Closes #7222
@ghost ghost added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label Aug 11, 2020
DHowett pushed a commit that referenced this issue Aug 24, 2020
)

If you scroll up to view the scrollback, then we want the viewport to
"stay in place", as new output comes in (see #6062). This works fine up
until the buffer circles. In this case, the mutable viewport isn't
actually moving, so we never set `updatedViewport` to true.

This regressed in #6062
Closes #7222

(cherry picked from commit bc642bb)
@ghost
Copy link

ghost commented Aug 26, 2020

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

Handy links:

@ghost
Copy link

ghost commented Aug 26, 2020

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

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Priority-2 A description (P2) 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.

3 participants