Make sure tooltip window handle is being destroyed when parent window/control is destroyed

[zorana-curkovic]

Inside Systems.Windows.Forms various dialogs and views use and create Tooltip window. The tooltip window is special in a way that is never added to the controls of the window which created the tooltip resulting in never being destroyed with the main window. After the tooltip window is used and domain reload happens, focusing on a newly created main window can result in a crash as the tooltip's registered class object no longer exists in memory.

This PR adds two things:

1. provides a way to set parent/owner for the tooltip window so it can be added to the controls of its owner to be destroyed when its owner is
2. Make sure that classes using the tooltip don't create it in their constructor as that is too early for registering with controls

The fix is applied to the following classes instantiating the tooltip:

• datagridview
• internalwindowmanager
• filedialog
• tabcontrol
• statusbar
• listview
• toolstriptextbox
• toolstrip
• toolbar
• treeview

Fix is not applied to the following classes instantiating tooltip as there is no obvious or guaranteed owner:

• helpprovider

• errorprovider

• Should this pull request have release notes?

  • Yes
  • No

• Do these changes need to be back ported?

  • Yes
  • No

• Do these changes need to be upstreamed to mono/mono or dotnet/runtime repositories?

  • Yes
  • No

Reviewers: please consider these questions as well! ❤️

An important note on these changes is that this PR will influence Unity's mono and may be submitted to the upstream. However, the user reporting this crash is using a third-party plugin (just System.Windows.Forms dll) generated from an unknown version of mono (similar to the case UUM-13189 ) which makes it more involved to get this fix over to them than just fixing it in Unity's stream.

Release notes

Fixed UUM-79065 @zorana.curkovic
Mono: Prevent the crash on domain reload when Windows Form is using a tooltip window.

6000.0
2022.3

[unity-cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[UnityAlex]

I see that you've indicated that these changes need to be upstreamed. Have you opened a PR for dotnet/runtime?

[zorana-curkovic]

I see that you've indicated that these changes need to be upstreamed. Have you opened a PR for dotnet/runtime?

I haven't. I would like to get an opinion from you guys. I'm not sure what kind of changes you usually submit to mono/mono.
My line of thoughts was - I would like this to be reviewed by someone who wrote or maintains this code, but that is all. My understanding is that if I do this it should just go to mono/mono, not dotnet/runtime. Is that right as well?

[joncham]

I see that you've indicated that these changes need to be upstreamed. Have you opened a PR for dotnet/runtime?

I haven't. I would like to get an opinion from you guys. I'm not sure what kind of changes you usually submit to mono/mono. My line of thoughts was - I would like this to be reviewed by someone who wrote or maintains this code, but that is all. My understanding is that if I do this it should just go to mono/mono, not dotnet/runtime. Is that right as well?

It is unlikely that anyone is maintaining or any original authors would review the Mono Windows Forms source at this point.

[UnityAlex]

I was more curious if you had noticed if the dotnet/runtime repository also had the same issue. They are actively taking changes and would be interested in this kind of fix. The changes look fine to me as well.