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

Buggy title bar appears in focus mode after long uptime #16221

Open
PennRobotics opened this issue Oct 24, 2023 · 7 comments
Open

Buggy title bar appears in focus mode after long uptime #16221

PennRobotics opened this issue Oct 24, 2023 · 7 comments
Labels
Area-Windowing Window frame, quake mode, tearout Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal.
Milestone

Comments

@PennRobotics
Copy link

PennRobotics commented Oct 24, 2023

Windows Terminal version

1.19.2682.0

Windows build number

10.0.19045.3570

Other Software

No response

Steps to reproduce

  1. Set up focus mode as the default for all sessions.
  2. Run Windows a reasonably long time without restarting
  3. Open a new terminal
  4. Sometimes (even now, not always) a title bar will appear

Expected Behavior

No title bar in focus mode

Actual Behavior

Title bar appears in focus mode—sporadically and after a long system uptime and resource usage.

The window cannot be dragged using the title bar, but the buttons (min/max/close) still function as expected. There are no tabs or text in the title bar.

Currently, I'm at 3:23:14:42 uptime after waking, vmmem was at 5.5 GB. (After the first crash, it is at 3.8 GB.) If I run a handful of wasteful tasks to run up resource usage (e.g. multiple ripgreps in Win command prompt and WSL at the same time) I can exceed 6 GB usage but this doesn't cause the title bar to appear in newly opened terminal processes.

This seems to be a problem independent of profile and other processes. I can run wt cmd and a title bar is there, then wt ubuntu and it's there, then wt powershell and it's no longer there, even though the other terminal processes are still open.

Restarting Windows will restore the expected behavior: no title bar

(update: unrelated to PID stored in a 16-bit variable; problem exists while all PIDs are under 23000)

@PennRobotics PennRobotics added 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 labels Oct 24, 2023
@PennRobotics
Copy link
Author

Related: #16211

@PennRobotics
Copy link
Author

Sometimes, the "not last" Settings menus will not crash.

@zadjii-msft
Copy link
Member

The settings thing is definitely separate bug from the focus mode ones. I'll try and narrow this thread down to just the focus mode ones.

I bet it's a pretty similar root cause though. Some sort of leftover state from the refrigeration/reheat.

@zadjii-msft zadjii-msft added Product-Terminal The new Windows Terminal. Area-Windowing Window frame, quake mode, tearout labels Oct 24, 2023
@carlos-zamora carlos-zamora added Needs-Repro We can't figure out how to make this happen. Please help find a simplified repro. Priority-3 A description (P3) and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Oct 24, 2023
@carlos-zamora carlos-zamora added this to the Backlog milestone Oct 24, 2023
@sim590
Copy link

sim590 commented Oct 24, 2023

I think that this happened after build 1.17.11461.0 and before 1.18.2681.0. I did try the following packages:

State Package
good Microsoft.WindowsTerminal_1.17.11461.0_8wekyb3d8bbwe.msixbundle
bad Microsoft.WindowsTerminal_1.18.2681.0_8wekyb3d8bbwe.msixbundle

I can reproduce this issue by simply opening a couple of instances of the terminal repeatedly. At some point, I get this bugged title bar:
image
It took me 4-5 tries here.

But on 1.17.11461.0, it never does that.

I would like to note also that I found a that version 1.18.2681.0 was significantly slower on startup compared to 1.17.11461.0 for some reason.

@zadjii-msft
Copy link
Member

That would track with my refrigeration assumption. That was introduced in #15424

@zadjii-msft zadjii-msft removed Needs-Repro We can't figure out how to make this happen. Please help find a simplified repro. Priority-3 A description (P3) labels Oct 24, 2023
@PennRobotics
Copy link
Author

Thanks for the updates.

I ran procmon and spy++ and a few other tools but didn't see any obvious difference between Windows, plus I need to get back to work. Using the info in this thread, it's now quite easy to repro: open two windows, close one, open another. Also, on one occasion, there were two "Settings" selections and both worked.

In any case, you definitely have a much better idea of what is occurring and how to remedy, so I'll bow out. Let me know if I can do anything else to help/test.

(I believe the other thread states this doesn't affect Windows 11 at all. I definitely appreciate the work keeping Terminal functional on older platforms. I have 10 at work and 11 at home, and I'm really much happier with 10 for a very large variety of rather small reasons.)

@exic
Copy link

exic commented Nov 23, 2023

FWIW, I'm experiencing this randomly with a uptime of <6,5 hours. I was trying to reproduce it with PowerShell and a clean settings.json, but couldn't get it. With WSL profile I have it every day and can reproduce more easily by opening a few instances. Windows 10 as well.
Any workarounds? Can I disable the refrigeration feature?
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Windowing Window frame, quake mode, tearout Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal.
Projects
Status: To Cherry Pick
Status: To Cherry Pick
Development

No branches or pull requests

5 participants