Skip to content

Fix possible hierarchy corruption during removing ComposePanel with LayerType.OnComponent #1132

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.

Sign up for GitHub

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

Draft
wants to merge 1 commit into
base: jb-main
Choose a base branch
from
Draft

Fix possible hierarchy corruption during removing ComposePanel with LayerType.OnComponent #1132

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/awt/ComposePanel.desktop.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,7 @@ import java.awt.event.FocusEvent
import java.awt.event.FocusListener
import java.util.*
import javax.swing.JLayeredPane
import javax.swing.SwingUtilities
import javax.swing.SwingUtilities.isEventDispatchThread
import org.jetbrains.skiko.GraphicsApi
import org.jetbrains.skiko.SkiaLayerAnalytics
Expand Down Expand Up @@ -235,7 +236,13 @@ class ComposePanel @ExperimentalComposeUiApi constructor(
override fun removeNotify() {
_composeContainer?.removeNotify()
if (isDisposeOnRemove) {
dispose()

// [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.
SwingUtilities.invokeLater {
Copy link
Collaborator

@igordmn igordmn Feb 21, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

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.

Copy link
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Member Author

Choose a reason for hiding this comment

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

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

It was in my head as a variant too

dispose()
}
}
super.removeNotify()
}
Expand Down