Question: Should we change the current teaching tip display behavior when updating the IsLightDismissEnabled property while the tip is open?

This question is about whether we should change the current behavior of changing the IsLightDismissEnabled property while the teaching tip is open. Note the documentation which describes the current behavior:

Some content and properties can be reconfigured while the teaching tip is open and will take effect immediately. Other content and properties, such as the icon property, the Action and Close buttons, and reconfiguring between light-dismiss and explicit-dismiss will all require the teaching tip to be closed and reopened for changes to these properties to take affect. Note that changing dismissal behavior from manual-dismiss to light-dismiss while a teaching tip is open will cause the teaching tip to have its Close button removed before the light-dismiss behavior is enabled and the tip can remain stuck on-screen.

Visualized, this behavior looks like this (changing IsLightDismissEnabled from false to true):

As the documentation describes correctly, at that point, the tip can no longer be closed by direct user interactions (Esc key doesn’t close tip and clicking elsewhere on the app UI surface (light-dismiss) also doesn’t close the tip).

As such, I would suggest we change the teaching tip implementation so that changes to the IsLightDismissEnabled setting will only take effect when the tip is re-opened. In other words, in the example above, enabling IsLightDismissEnabled will not change the opened tip’s UI at all (the close button will remain visible and the tip’s background stays the same) and only the the re-opened tip will reflect these changes.

Reading through the documentation quoted above “[…]reconfiguring between light-dismiss and explicit-dismiss will […] require the teaching tip to be closed and reopened for changes to [this property] to take affect”, it seems to me that the suggested behavior is the intended behavior and the current behavior we are seeing sounds more like a bug which should be fixed.

@StephenLPeters @SavoySchuler FYI (as the team members who worked on the TeachingTip).

[Felix-Dev]

@StephenLPeters @robloo Seeing as this is not likely to be a critical issue (i.e. this is, to my recollection, the first time the current behavior was mentioned to be an issue) I’d be fine if we broaden the scope here and create a tracking issue for the Popup control and its IsLightDimissEnabled API (to be fixed with winui 3 later next year).

We can always re-evaluate this decision if the need arises but this looks to be a fix which would be “nice to have” for now and not something critical.

Would you guys be fine with that?

[robloo]

@Felix-Dev This definitely seems to be an issue with the Popup that needs to be better handled in the future. The TeachingTip would then just pass along the value and not worry about different states. If it’s too complicated to fix it’s also something I would be fine documenting with a warning not to change it while the pop-up is open (although it still needs to avoid getting stuck open).