-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Description
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
- Launch lazygit
- Stage any file
- Open the commit message panel - c key
- While it is open, click another side tab(Files, Branches, etc..)
- Notice the summary closes but the description panel remains on screen
Expected behavior
A clear and concise description of what you expected to happen.
Since the commit message panel behaves like a popup/modal style UI, I would expect either:
- the whole panel to close when switching tabs
- or tab switching to be blocked while the panel is active
At the moment only part of the panel is dismissed, which leaves the UI is an inconsistent state
Screenshots
If applicable, add screenshots to help explain your problem.
Version info:
- Run
lazygit --versionand paste the result here
❯ lazygit --version
commit=, build date=, build source=Homebrew, version=0.58.1, os=darwin, arch=arm64, git version=2.52.0Terminal info:
What terminal are you using, and which version? For some types of bugs this information can be relevant.
- iTerm 2(MacOS 26.2 Tahoe)
- zsh 5.9
Additional context
Add any other context about the problem here.
From a quick look through the tab click handling and panel lifecycle flow, it seems there are two reasonable directions here:
- Block tab switching while the commit message panel is open
- Automatically close the commit message panel on tab switch
I tried both approaches locally in separate branches just to confirm the behaviour changes:
- Option 1 : block tab switching
- Option 2 : close panel on tab switch
Personally, reading the general tone of the VISION.md notes, option 2 feels slightly more aligned with the intended UX flow. That said, this sits fairly close to UX policy, so I thought it would be better to check first and align on direction before putting together a proper PR.
I also had a look at adding a test for this, but because the tab click path is mouse/coordinate driven in the integration layer, I was not fully confident I was doing that in a stable way.
Happy to include a test if there is a preferred pattern for this kind of interaction :)
Note
Please try updating to the latest version or manually building the latest master to see if the issue still occurs.