Fix possible hierarchy corruption during removing ComposePanel with LayerType.OnComponent

[MatkovIvan]

Proposed Changes

• dispose might trigger hierarchy change for example removing LayerType.OnComponent layers. That will conflict with removing this ComposePanel. To avoid such issues we need to call dispose after leaving this method.

Testing

Test: remove ComposePanel when it has opened layers attached to its parent

[igordmn]

Using any dispatching should be the last resort, as it introduces race conditions. One of the race conditions that came to my mind is:

val frame = JFrame()
frame.isVisible = true

val panel = ComposePanel()
frame.add(panel) // addNotify, init scene
frame.remove(panel) // removeNotify, dispatch dispose
frame.add(panel) // reinit scene, leak the old scene
...
// dispose the new scene

We can write a warding code for this race, but let's discuss alternatives first. Do I understand correctly that we have an issue with this hierarchy:

Window
  ContentPane
    ComposePanel
    Layer1  // created/removed by ComposePanel
    Layer2  // created/removed by ComposePanel

Do we have a crash or it is incorrect behaviour because of internal AWT state corruption?

Will moving layers into its own container help?

Window
  ContentPane
    ComposePanel
    Layers
      Layer1  // created/removed by ComposePanel
      Layer2  // created/removed by ComposePanel

Also, worth to write a test, if it's not difficult.

[igordmn]

Another alternative - disposing the scene without dispatching, but dispatch removing of the layers if they are removed in removeNotify (with the same race warding). It will be more safe, and closer to the issue.

[MatkovIvan]

Do we have a crash or it is incorrect behaviour because of internal AWT state corruption?

Some kind of. Sometimes it's an out-of-bounds crash, sometimes it just leads to a corrupted state without a crash

Will moving layers into its own container help?

1. It's controlled by the user
2. Layers (windowContainer) should be logically one of the parents of ComposePanel

but yes, it will avoid calling remove inside another remove call of the same container

Also, worth to write a test, if it's not difficult.

Sure. Initially this PR is a push of not planned fix from local stash with the main intention to discuss the problem. Let me convert it to draft to make it more clear

[MatkovIvan]

disposing the scene without dispatching, but dispatch removing of the layers

It was in my head as a variant too