Resizing terminal window destroys both powerline formatting and text layout

jessey-git commented 11 months ago

Windows Terminal version

1.19.2682.0

Windows build number

10.0.22621.0

Other Software

Oh My Posh [JanDeDobbeleer.OhMyPosh] Version: 18.10.3

Steps to reproduce

Here's 2 situations, see screenshots for examples as well.

Example 1

Start with a working powerline prompt like what you get with "oh-my-posh" [1]
Maximize the terminal window - see the fonts and formatting break [2]
Unmaximize and see the brokenness still [3]

Example 2

Start with a maximized window and execute a long command that will scroll the screen. Like cat a long file.
Minimize the window -- notice that the cursor is in the wrong spot and layout is hosed (the gci command) [4]

[1] [2] [3] [4]

Expected Behavior

While it 'tis the season... expected behavior is for nothing spooky to happen! Look at those poor powerline fonts reduced to their skeletons! And what is my text doing in the wrong spots faints

Actual Behavior

See repro steps.

zadjii-msft commented 10 months ago

HMM this seems a little bit like the "the colors on my prompt disappeared" thing that @DHowett saw in the bug bash last week, and a little bit like the scrolling thing that was noted in #16034. I don't know for sure if they're the same thing.

I'll tag this up for 1.19 servicing. We'll try and use these notes to get a solid repro and make sure that it all gets cleaned up. Thanks!

bslote commented 9 months ago

FWIW this doesn't happen with older versions of oh-my-posh. I have 2 machines with identical configurations except for omp version:

Machine A)

Terminal 1.19.2682.0
omp 12.28.2

Machine B)

Terminal 1.19.2682.0
omp 18.22.0

This problem only occurs on machine B, so I wonder if this might actually be a bug with omp, but if it isn't then it should be possible to bisect whatever changed in omp that is causing the issue in Terminal.

jessey-git commented 9 months ago

It's not occurring with Terminal 1.18.2822.0 so my bet is still on something primarily with Terminal.

jessey-git commented 6 months ago

Still broken on Terminal 1.20.10293.0

jessey-git commented 6 months ago

@zadjii-msft @DHowett With the other issue mentioned above having been closed but v1.20 still showing this issue for me, is it possible to take another look now?

DHowett commented 6 months ago

Absolutely. Thanks! This bites me on the regular as well, but if I could nail down some repro steps I'd love it.

jessey-git commented 6 months ago

Hmm, don't the repro steps up above hit the problem for you? Both examples are still 100% repro for me here.

Willovent commented 5 months ago

I'm facing this issue right now trying some new configs. I reproduce this as soon as I use one rprompt block. If I change it to prompt, everything works fine.

jessey-git commented 5 months ago

Good find! The usage of a rprompt does seem related to both of my cases above. Though, in my case at least, using the regular "type": "prompt" field but keeping "alignment": "right" also yields odd rendering for my two scenarios as well.

Here's a full configuration block to play with:

    {
      "alignment": "right",
      "segments": [
        {
          "background": "#306090",
          "foreground": "#ffffff",
          "leading_diamond": "\ue0b2",
          "style": "diamond",
          "template": " meow ",
          "type": "text"
        }
      ],
      "type": "rprompt"
    },

thomaslevesque commented 5 months ago

@jessey-git your workaround seems to work for me, thanks! So it might be a bug in OMP... Do you know if there's already an open issue in OMP that I can subscribe to?

jessey-git commented 5 months ago

No, I filed the bug here because I noticed it back during the transition from Terminal 1.18 to 1.19. At that time the same version of OMP worked completely fine in 1.18 but failed in 1.19 so I took that as indication it was a Terminal bug.

zadjii-msft commented 5 months ago

quick question before I dig in more - @jandedobbeleer this look familiar?

JanDeDobbeleer commented 5 months ago

@zadjii-msft I wonder what version of oh-my-posh is being used here and if this is still reproducible using the latest. rprompt used ANSI sequences to position the cursor all the way to the right, then move the cursor back based on the length of the right aligned block or prompt. However, lately I moved that to spaces instead, so that logic is gone. Would be cool if we could validate that.

Willovent commented 5 months ago

I'm using oh-my-posh 19.18.1 and still reproducing right now

jessey-git commented 5 months ago

Same 19.18.1 version of OMP here right now and still reproduces. The version that I was using at the time of initial filing is still in original message too in case that's helpful.

JanDeDobbeleer commented 5 months ago

In that case I have no idea. rprompt uses ANSI to store and restore the cursor position, but a right aligned block only uses spaces so there's nothing that could influence coloring in a way.

zadjii-msft commented 5 months ago

Well, thanks for the quick look at least! I'll try and get a local repro setup

sba923 commented 3 months ago

Problem still present in Preview v1.21.1272.0

sba923 commented 1 month ago

Problem still present in Preview v1.21.1772.0

DHowett commented 1 month ago

This turned out to be a fun one! Assigning myself, PR to follow.

DHowett commented 2 weeks ago

Huh, we never linked this up to the PR that fixed it.

DHowett commented 2 weeks ago

Fixed in #17568, currently available in Canary, will be backported to 1.21 before it goes out as Stable; we may also choose to service 1.20 stable.

Funny enough, if your prompt was on a line number that was evenly divisible by 128 when you resized, you would not have experienced this bug (!)

microsoft / terminal