Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tray Icon PR followup #10938

Merged
4 commits merged into from
Aug 19, 2021
Merged

Tray Icon PR followup #10938

4 commits merged into from
Aug 19, 2021

Conversation

leonMSFT
Copy link
Contributor

Some followups to #10368:

  • Accidentally reverted a defapp change where the Monarch should not by default register itself as a handoff server.
  • Destroy the tray icon if we're a monarch otherwise if we're a quake window we request the monarch to hide the icon.

@leonMSFT leonMSFT added Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal. Area-User Interface Issues pertaining to the user interface of the Console or Terminal labels Aug 12, 2021
@leonMSFT leonMSFT added the Needs-Second It's a PR that needs another sign-off label Aug 13, 2021
}
else if (_window->IsQuakeWindow())
{
_HideTrayIconRequested();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bad idea; _HideTrayIconRequested is a coroutine that takes an implicit reference to this, and you're dispatching it out of the destructor. By the time the resume_backround resumes you, this will have been destroyed.

This needs to be restructured such that (1) the destructor never uses anything that requires a living this to persist after the destructor returns and (2) it is as small as possible 😄

(Also, there's no guarantee that AppHost will be destructed.)

Copy link
Member

@lhecker lhecker Aug 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, there's no guarantee that AppHost will be destructed.

It's a regular instance in wWinMain. It should be destroyed properly unless the app abort()s, right?

We could make a _HideTrayIconRequestedAsync and have _HideTrayIconRequested run synchronously.
BTW _HideTrayIconRequested accesses settings from a background thread which is a race condition... I think I should add thread asserts to CascadiaSettings. 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a regular instance in wWinMain. It should be destroyed properly unless the app abort()s, right?

Yes. That does assume that main exits normally. If we were more like a standard UWP Xaml application, we would actually ExitProcess/TerminateProcess when the window was destroyed. The fact that we do not makes us uncommon in the world of Xaml, and is the cause for some of our "this object was already disposed of!" error traces on shutdown in debug mode. 😄

(Because of that, we've entertained the idea multiple times of switching -- it would clear up almost all of our on-exit crashes that originate deep inside Windows.UI.Xaml.dll!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm then I guess an alternative might be to do this particular Tray Icon cleanup in something like LastTabClosed?

Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as noted

@ghost ghost added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Aug 13, 2021
Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@@ -656,9 +660,6 @@ void AppHost::_BecomeMonarch(const winrt::Windows::Foundation::IInspectable& /*s
{
_setupGlobalHotkeys();

// The monarch is just going to be THE listener for inbound connections.
_listenForInboundConnections();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this change. Otherwise I'd approve this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh this was originally removed as part of this defapp bug fix #10823, and my bad merge left it in 😥. In short, the fix made it so that instead of making the monarch receive default terminal handoffs by default, the monarch should first figure out which peasant (or itself) should handle a default terminal handoff and tell that window to receive the connection.

@@ -324,6 +319,15 @@ void AppHost::AppTitleChanged(const winrt::Windows::Foundation::IInspectable& /*
// - <none>
void AppHost::LastTabClosed(const winrt::Windows::Foundation::IInspectable& /*sender*/, const winrt::TerminalApp::LastTabClosedEventArgs& /*args*/)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you might hate me for asking . . . but does this fire when you use the [x] on the window? I know that we try to kill all the tabs, but this might only be a side effect... unless it is the main effect 😀

Copy link
Contributor Author

@leonMSFT leonMSFT Aug 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does in fact go off on the X button 🙂

@DHowett
Copy link
Member

DHowett commented Aug 16, 2021

We might want to throw an auto strongThis{ get_strong() }; in _HideTrayIconRequested, which will guarantee that it stays alive across the coroutine boundary. Otherwise, things could still get dicey.

@DHowett
Copy link
Member

DHowett commented Aug 16, 2021

(just right at the top, but inside the if constexpr)

@DHowett DHowett added the AutoMerge Marked for automatic merge by the bot when requirements are met label Aug 19, 2021
@ghost
Copy link

ghost commented Aug 19, 2021

Hello @DHowett!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 482dcec into main Aug 19, 2021
@ghost ghost deleted the dev/lelian/notifyicon/followup branch August 19, 2021 17:38
@ghost
Copy link

ghost commented Aug 31, 2021

🎉Windows Terminal Preview v1.11.2421.0 has been released which incorporates this pull request.:tada:

Handy links:

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal AutoMerge Marked for automatic merge by the bot when requirements are met Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Second It's a PR that needs another sign-off Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants