Discussion: Commit description panel remains visible after tab switch when commit message panel is open

[DokaDev]

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

1. Launch lazygit
2. Stage any file
3. Open the commit message panel - c key
4. While it is open, click another side tab(Files, Branches, etc..)
5. 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 --version and paste the result here

❯ lazygit --version
commit=, build date=, build source=Homebrew, version=0.58.1, os=darwin, arch=arm64, git version=2.52.0

Terminal 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:

1. Block tab switching while the commit message panel is open
2. 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.

[stefanhaller]

The bug is that mouse interactions in windows behind a popup should be blocked (except for scrolling with the wheel). Popups are modal, you need to dismiss them before you can interact with views behind them again.

Your fix of Option 1 is not going far enough; we should also block clicks in the content of views behind a popup (and I could swear that this used to work at some point in older versions).

I didn't have a closer look yet, but my current feeling is that this needs a fix in gocui.

[stefanhaller]

@DokaDev Finally got around to having a look. Here's a PR: #5313. You may want to try if this works for you before I merge.