Cannot use ALT to split panes after opening Close... tab submenu #11046

Closed
opened 2026-01-31 02:37:07 +00:00 by claunia · 5 comments
Owner

Originally created by @DHowett on GitHub (Oct 16, 2020).

Environment

Windows Terminal version (if applicable): 1.5.2892

Regression from #7728.

It looks like every time we try to split a pane, we try to re-register the menu items against the tab.
We try to reparent the menu items into a new context menu. Because of that, we eat an exception that they already have parents.

All Tab event registration fails afterwards for that tab.

Originally created by @DHowett on GitHub (Oct 16, 2020). # Environment ```none Windows Terminal version (if applicable): 1.5.2892 ``` Regression from #7728. It looks like every time we try to _split a pane_, we try to re-register the menu items against the tab. We try to reparent the menu items into a new context menu. Because of that, we eat an exception that they already have parents. All Tab event registration fails afterwards for that tab.
Author
Owner

@DHowett commented on GitHub (Oct 16, 2020):

(/cc @mpela81, if you want to have a fun debugging session 😄)

@DHowett commented on GitHub (Oct 16, 2020): (/cc @mpela81, if you want to have a fun debugging session :smile:)
Author
Owner

@mpela81 commented on GitHub (Oct 16, 2020):

Fantastic 😄

As far as I can see, when splitting panes we call Tab::Initialize again, which re-builds the context menu from scratch. But we keep a reference to the closeTabsAfter/closeOtherTabs sub-menu items (to enable/disable them at runtime), so the same end up being appended to a new parent and 💣

To fix it, we could re-create the sub-items as well. Alternatively, the question is why creating the context menu again in the first place?

@mpela81 commented on GitHub (Oct 16, 2020): Fantastic 😄 As far as I can see, when splitting panes we call `Tab::Initialize` again, which re-builds the context menu from scratch. But we keep a reference to the closeTabsAfter/closeOtherTabs sub-menu items (to enable/disable them at runtime), so the same end up being appended to a new parent and 💣 To fix it, we could re-create the sub-items as well. Alternatively, the question is why creating the context menu again in the first place?
Author
Owner

@DHowett commented on GitHub (Oct 16, 2020):

why creating the context menu again in the first place?

If I had to guess, I'd say... "oversight"!

@DHowett commented on GitHub (Oct 16, 2020): > why creating the context menu again in the first place? If I had to guess, I'd say... "oversight"!
Author
Owner

@mpela81 commented on GitHub (Oct 16, 2020):

why creating the context menu again in the first place?

If I had to guess, I'd say... "oversight"!

so... we could just move the _CreateContextMenu() call to the Tab's constructor, couldn't we?

@mpela81 commented on GitHub (Oct 16, 2020): > > > > why creating the context menu again in the first place? > > If I had to guess, I'd say... "oversight"! so... we could just move the `_CreateContextMenu()` call to the Tab's constructor, couldn't we?
Author
Owner

@ghost commented on GitHub (Nov 11, 2020):

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

Handy links:

@ghost commented on GitHub (Nov 11, 2020): :tada:This issue was addressed in #7961, which has now been successfully released as `Windows Terminal Preview v1.5.3142.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.5.3142.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11046