[Window] Pressing a header command button while the window is fullscreen will make it floating

[russellbanks]

Bug Description

Pressing a header command button while the window is fullscreen will make it floating (without even changing the state).

Here is a minimal amount of code to reproduce this behaviour:

fun main() = auroraApplication {
    val windowState = rememberWindowState()
    AuroraWindow(
        skin = marinerSkin(),
        state = windowState,
        onCloseRequest = ::exitApplication,
        menuCommands = CommandGroup(
            commands = listOf(
                Command(
                    text = "Fullscreen Top",
                    secondaryContentModel = CommandMenuContentModel(
                        CommandGroup(
                            commands = listOf(
                                Command(
                                    text = "Fullscreen",
                                    action = {
                                        if (windowState.placement == WindowPlacement.Floating) {
                                            windowState.placement = WindowPlacement.Fullscreen
                                        } else {
                                            windowState.placement = WindowPlacement.Floating
                                        }
                                    }
                                )
                            )
                        )
                    )
                )
            )
        )
    ) {

    }
}

NVIDIA_Share_DdMDm9Vkjs.mp4

Platform Info

Aurora Version: Tested on both 1.1.0 and 1.2-SNAPSHOT (1.2-20220513.221833-4)

[kirill-grouchnikov]

Not seeing this on my Mac. Is this specific to a certain OS or Java version?

[kirill-grouchnikov]

Looks like when the window is in fullscreen mode, pressing the "Fullscreen Top" menu activates the first menu command in it. That shouldn't happen, but if it's on a platform that I don't have access to, all I can do is point you to a few places in the code to debug.

Right now, can you add a println statement in your action block and see when it's getting invoked. It should be invoked on press+release of the "Fullscreen" menu item, not on pressing the "Fullscreen Top" menu.

[russellbanks]

Not seeing this on my Mac. Is this specific to a certain OS or Java version?

• The example above is using Windows 11 with Java 17.
• I have also tested it on Manjaro Linux using Java 17 and I am experiencing the issue there too.
• I am unable to test it on MacOS.

Right now, can you add a println statement in your action block and see when it's getting invoked. It should be invoked on press+release of the "Fullscreen" menu item, not on pressing the "Fullscreen Top" menu.

I have done this and the odd thing is that it only gets invoked when the correct button is pressed (so the sub-button here). Therefore, when the window is fullscreened and you press the topmost button and it becomes floating, nothing is supposedly getting invoked.

Looks like when the window is in fullscreen mode, pressing the "Fullscreen Top" menu activates the first menu command in it.

I don't believe this is the case as setting this up with other command menu buttons will still make the window floating when they are pressed despite their menus having nothing to do with managing the window state.

[kirill-grouchnikov]

It's not that it becomes floating. All Aurora popups are floating, anchored where they should. It's that the menu is displayed where it should, but the menu item action gets invoked incorrectly and your window exits the fullscreen mode, leaving that menu hanging in the corner.

[kirill-grouchnikov]

In this scenario, what is the codepath that moves the window back to WindowPlacement.Floating if it's not the action associated with the "Fullscreen" command?

[russellbanks]

The menu item action gets invoked incorrectly and your window exits the fullscreen mode, leaving that menu hanging in the corner.

In my app (below) that has more buttons that don't have anything to do with window state, pressing them will also change the window in this way.

NVIDIA_Share_MwPaegS6dA.mp4

In this scenario, what is the codepath that moves the window back to WindowPlacement.Floating if it's not the action associated with the "Fullscreen" command?

The thing is it's not even fully moving the window back to WindowPlacement.Floating because as you will notice, I have to press the button again (which won't do anything) and then press it once more before it does anything, implying that it remains fullscreen in the state despite not actually being fullscreen.

[kirill-grouchnikov]

So it looks like when the window is in Fullscreen placement, clicking any top-level menu moves the window back to Floating placement, and then also open the matching popup menu in the "old" location that corresponds to the fullscreen placement.

Does that transition back to floating placement only happen on clicking the menu buttons, or any other button in your app, say "Calculate" for example. In general, there's nothing special about the menu buttons in Aurora. They just happen to be displayed along the top edge of the window, but that's about it.

[russellbanks]

Does that transition back to floating placement only happen on clicking the menu buttons, or any other button in your app, say "Calculate" for example.

Weirdly enough no - it only seems to be those top buttons.

NVIDIA_Share_Hos53ER4h2.mp4

[kirill-grouchnikov]

It probably fires twice, once for key press and once for key release

[russellbanks]

Do you have any idea why the header buttons act this way however?

[kirill-grouchnikov]

One more question. What happens when you click to the right of the menu buttons? Same area around the top edge of the fullscreen window, but not on any Aurora menu button?

[russellbanks]

One more question. What happens when you click to the right of the menu buttons? Same area around the top edge of the fullscreen window, but not on any Aurora menu button?

As below, it only occurs on the button press:

NVIDIA_Share_9grwTcViCR.mp4

[kirill-grouchnikov]

        LaunchedEffect(null) {
            window.addComponentListener(object: ComponentListener {
                override fun componentHidden(e: ComponentEvent?) {
                }

                override fun componentMoved(e: ComponentEvent?) {
                }

                override fun componentShown(e: ComponentEvent?) {
                }

                override fun componentResized(e: ComponentEvent?) {
                    println("Resized! ${window.size}")
                    for (line in java.lang.RuntimeException().stackTrace)
                        println(line)
                }
            })
        }

prints out where the window resizing happens, but unfortunately it's happening as a separate event, so there's nothing from Compose or Aurora in there

[kirill-grouchnikov]

This is where you can put a breakpoint. Menu buttons are command buttons, and this is where Aurora calls the action block.

This is where Compose Desktop tracks the placement as mutable state, so the updates to the underlying state probably happen on the next frame. Which is why there's nothing from Compose or Aurora in there.

If I can reproduce this on my Windows 10 machine, I'll start removing Aurora pieces to see if this is Aurora specific or not.

[kirill-grouchnikov]

I can reproduce on Windows 10

[kirill-grouchnikov]

If I add println(windowState.placement) block in the window, it prints Fullscreen when the top level menu is clicked and the window goes back to its initial state. Then, clicking on the menu item itself, results in printing Floating.

Don't want to say that this is Aurora or not yet. I'll need to see if I can reproduce this without any Aurora code.

[kirill-grouchnikov]

I believe this is somewhere in Compose Desktop's handling of fullscreen mode. This is the stacktrace (bottom left) on clicking that top-level menu when the window is fullscreen:

And this is the same stack trace a little bit deeper in PlatformOperations showing that Compose Desktop is deciding to quit the fullscreen mode:

It'll probably take me a bit more time to get a reproducer without Aurora in it to file on Compose Desktop. Meanwhile tagging @igordmn for visibility into this

[kirill-grouchnikov]

Looking at the code a bit, I believe this is incorrect on the Compose desktop side. Aurora implements its popups as separate ComposeWindows, and here in this flow when this popup window (coming from the main top-level fullscreen window) is shown, the code treats this as a signal that the main window should exit its fullscreen mode.

[igordmn]

This is the stacktrace (bottom left) on clicking that top-level menu when the window is fullscreen:

backedLayer.fullscreen doesn't do anything on Windows/Linux, so this code block shouldn't affect the issue.

Sorry, I was mistaken. Could you make a reproducer for the issue in pure Compose?

[igordmn]

the code treats this as a signal that the main window should exit its fullscreen mode

I am starting to understand. If we have two windows, the second window changes the global variable responsible for the current fullscreen window