Make Pane a proper WinRT type

[zadjii-msft]

Pretty self explanatory. Right now they're plain c++ types, but in reality they should be exposed as projected WinRT types, so they can be used across binary boundaries.

[zadjii-msft]

We may be able to fix MSFT:45168090¹ and MSFT:40737566² with this. Those are both crashes in Pane because pane is setting up event handlers, using this as the callback target, but the event fires after the pane is released (which doesn't actually unregister the callback).

Footnotes

1. TerminalPage::_updateThemeColors ↩

2. Pane::_ControlGotFocusHandler ↩

[lhecker]

Huh, but aren't we already using enable_shared_from_this<Pane>? Of the 17 places in Pane.cpp that use this only 2 use it unsafely without event revoker: _borderFirst/Second.Tapped(). They call _FocusFirstChild and that would match the second bug right? TerminalPage sets up the GotFocus event handlers which calls _UpdateActivePane, which then invokes the ActivePaneChanged event handlers, which TerminalPage is subscribed to, which then calls _updateThemeColors. That would explain the first bug.

In short, I think we can hotfix the two bugs right now if we use event revokers for _borderFirst/Second.Tapped() in Pane.cpp. All the other event handlers already do it too. Does that make sense? Should I do it?

That aside: FWIW strictly using projected types may make implementing certain algorithms more difficult / less effective, like WalkTree which is currently being used in a number of places outside of Pane.cpp.

[zadjii-msft]

I think these guys might be part of it too:

terminal/src/cascadia/TerminalApp/Pane.cpp

Lines 46 to 48 in 6cff135

	// Register an event with the control to have it inform us when it gains focus.
	_gotFocusRevoker = _control.GotFocus(winrt::auto_revoke, { this, &Pane::_ControlGotFocusHandler });
	_lostFocusRevoker = _control.LostFocus(winrt::auto_revoke, { this, &Pane::_ControlLostFocusHandler });

Because they're registered to this, they don't get revoked when the pane is Closed.

(I can't recall if I got those in a drive-by for #997 or not)

[lhecker]

Oh, is there a difference between a pane closing and a pane being deallocated? I hoped it would only be a problem when a pane is deallocated and the this pointer is actually invalid.

[zadjii-msft]

Wait now I honestly don't know. It seems like releasing the last ref to the shared_ptr would dtor the Pane, and that would automatically clean up the _gotFocusRevoker & _lostFocusRevoker, so that they couldn't be called back at this point. Maybe there's a time slice where the smart pointer is invalid, but before the pane is actually deallocated. Maybe, if at exactly that slice, the shared_from_this call explodes