Title event handler attached to control on tab discards title variable

[miniksa]

terminal/src/cascadia/TerminalApp/Tab.cpp

Lines 320 to 328 in 9145903

	control.TitleChanged([weakThis](auto newTitle) {
	// Check if Tab's lifetime has expired
	if (auto tab{ weakThis.lock() })
	{
	// The title of the control changed, but not necessarily the title of the tab.
	// Set the tab's text to the active panes' text.
	tab->SetTabText(tab->GetActiveTitle());
	}
	});

I'm trying to make the Telnet and Azure connection types set a title when they start up on the tab.

They're calling the ESC]0;<title>BEL sequence on the output handlers to make it happen.

Turns out that title makes it all the way to here and then is completely discarded in favor of whatever's already on the title.

[miniksa]

@zadjii-msft, this is the thing I was talking about.

[DHowett-MSFT]

I looked into this. Emitting a title during Start() forces Pane to ask Control for its title before _initializedTerminal is true.

We need to rework the title eventing, and also fix starting titles to actually apply to the terminal instead of letting conhost spout it back at us.

[zadjii-msft]

For the record, discarding the value of newTitle is intentional here. The Tab doesn't have a TitleChanged event, only the control does. So we hook up a handler to every control's TitleChanged event as a way of getting notified that the Tab's title might have changed.

We maybe should just set the Tab's title to the StartingTitle of the first control added to the tab, if that property is set, rather than waiting for the title to roundtrip through conpty to us.

[zadjii-msft]

@miniksa do we think this is still important? At some point, we changed Terminal::GetConsoleTitle to return the _startingTitle if the title isn't set by VT. Looks like that was in #6433, which was roughly the 1.1 timeframe.

You can go ahead and reopen if you want to veto.

[miniksa]

Nah its fine thanks.