I tested for the bug on Windows and the window never become visible :/
when I try to dbg!(frames.0) it never print anything in the console.

thanks for testing! could you debug the event in the event loop and copy the log of events for the first few seconds when running the example on windows?
here:

events:

[crates\bevy_winit\src\lib.rs:377] &event = NewEvents(
    Init,
)
[crates\bevy_winit\src\lib.rs:377] &event = Resumed
[crates\bevy_winit\src\lib.rs:377] &event = WindowEvent {
    window_id: WindowId(
        WindowId(
            3934682,
        ),
    ),
    event: Resized(
        PhysicalSize {
            width: 500,
            height: 300,
        },
    ),
}
[crates\bevy_winit\src\lib.rs:377] &event = AboutToWait
[crates\bevy_winit\src\lib.rs:377] &event = NewEvents(
    WaitCancelled {
        start: Instant {
            t: 97434.7408719s,
        },
        requested_resume: None,
    },
)
[crates\bevy_winit\src\lib.rs:377] &event = DeviceEvent {
    device_id: DeviceId(
        DeviceId(
            10813529,
        ),
    ),
    event: Added,
}
[crates\bevy_winit\src\lib.rs:377] &event = DeviceEvent {
    device_id: DeviceId(
        DeviceId(
            134547849,
        ),
    ),
    event: Added,
}
[crates\bevy_winit\src\lib.rs:377] &event = DeviceEvent {
    device_id: DeviceId(
        DeviceId(
            212731889,
        ),
    ),
    event: Added,
}
[crates\bevy_winit\src\lib.rs:377] &event = DeviceEvent {
    device_id: DeviceId(
        DeviceId(
            148442009,
        ),
    ),
    event: Added,
}
[crates\bevy_winit\src\lib.rs:377] &event = DeviceEvent {
    device_id: DeviceId(
        DeviceId(
            65603,
        ),
    ),
    event: Added,
}
[crates\bevy_winit\src\lib.rs:377] &event = AboutToWait

I did some fixes for Windows:

• Windows gets fewer RedrawRequested events at start, so I'm forcing to send at least 5 on application start. This feels a bit hackish but I don't think it should be an issue
• Windows doesn't send events if there are no visible windows. now this case is handled on its own by triggering a manual update

For the button example, it should be a partial fix, for the first steps with the transparent window.

the fact that it's not updated is "work as intended", or the bug is in rendering ordering, not in windows management: ui nodes are queued before they are extracted, so the state being drawn is the one from the previous update. extract_uinodes runs after queue_uinodes

I did not have that issue because I'm on a macOS laptop and using the touchpad, which sends events for touch pad pressure and I'm not maintaining the exact same constant pressure so new events are send continuously while clicking

ui nodes are queued before they are extracted

I'm not sure I follow. In

queue_uinodes is put in the Queue render set, which is part of the Render schedule, which is the "main" schedule of the render app. As the SubApp::new documentation says, the "main" schedule will always run after the 2nd argument to SubApp::new is ran. In the case of the RenderApp, the 2nd argument to SubApp::new calls extract, which itself runs the ExtractSchedule. So indeed, queue_uinodes is ran after extract_uinodes, and before rendering.

My best guess would be that the input change has 1 frame of latency. Looking at Interaction, it's updated in ui_focus_system which itself is scheduled after InputSystem, in PreUpdate, which is before button_system, so not that. But what? hmm idk

@nicopap could you try running the button example on this branch? https://github.com/mockersf/bevy/tree/button-ui-system-order

It's just adding some prints. I don't have access to a windows anymore so I'm going from memory of what I saw earlier, but the green background was extracted and not queued on the first click, and the extract system was running after the queue system