Window freezes when `FileDragAndDrop` Event is triggered in the `drag_and_drop` example

[jakemoran]

Bevy version

0.16.0

Relevant system information

AdapterInfo { name: "AMD Radeon RX 6700 XT", vendor: 4098, device: 29663, device_type: DiscreteGpu, driver: "32.0.13031.3015", driver_info: "", backend: Dx12 }

SystemInfo { os: "Windows 10 Pro", kernel: "19045", cpu: "Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz", core_count: "6", memory: "16.0 GiB" }

cargo 1.85.0 (d73d2caf9 2024-12-31)

What you did

Run the drag_and_drop example and attempt to drop a file onto the window.

What went wrong

When hovering a file over the window and triggering a FileDragAndDrop event, the window freezes and the event is not logged.

The issue seems to be intermittent, sometimes I can drag and drop files with no issues but then the freeze occurs again after rerunning the example.

Additional information

Resizing the window causes it to unfreeze, suggesting this might be related to #18065?

My app is dependent on the user supplying data by dropping a file onto the window, so this is currently blocking my upgrade to 0.16.

To work around it, I need to drop my version of bevy_window to 0.15.2. I see the same issue when using 0.15.3, similar to the issue I linked above.

Relevant dependency versions (let me know if I'm excluding any important ones):

accesskit_winit: 0.25.0
raw-window-handle: 0.6.2
winit: 0.30.10

[alice-i-cecile]

For anyone reading: I'd appreciate tests on other OS's. That would help us determine where the problem might be.

[zachbateman]

I'm also encountering this exact same issue on Windows while updating from Bevy 0.14.2 to 0.15.3. It looks like the problem was introduced in 8628545.

Reverting bevy_winit/src/state.rs back to Bevy 0.15.2 seems to fix the problem for me.

[alice-i-cecile]

cc @aloucks

[aloucks]

I'm unable to reproduce it on Windows 11 and I don't have a Windows 10 machine to test with.

Right clicking the title bar is an issue with the way Windows integrates system menus and such. The window enters the "modal" loop when you right click which pauses the main event loop. The only way that I'm aware to correctly fix that is by putting the input processing in a different thread from the app simulation and rendering threads. Bevy's app simulation is strongly integrated into the input processing thread.

With that said, I don't think this issue is directly related to the right-click-title-bar problem.

@zachbateman Are you also on Windows 10 or can you reproduce on Windows 11?

Does changing the WinitSettings focused_mode and unfocused_mode to Continuous have any effect?

bevy/crates/bevy_winit/src/winit_config.rs

Lines 18 to 23 in 3b24f52

	pub fn game() -> Self {
	WinitSettings {
	focused_mode: UpdateMode::Continuous,
	unfocused_mode: UpdateMode::reactive_low_power(Duration::from_secs_f64(1.0 / 60.0)), /* 60Hz, */
	}
	}

[zachbateman]

@aloucks I'm using Windows 11.

Changing WinitSettings focused_mode and unfocused_mode to UpdateMode::Continuous via a Startup system does not seem to have any effect.

More specifically: I'm seeing the window freeze when dragging a file into the window for a drag-and-drop. However, it looks like the window freezes as soon as the cursor enters the window with the drag, and remains frozen even if I do not drop the file in the application (take it back out). As @jakemoran mentioned, resizing the window is the only way I have found to break the freeze.

Curiously, running an Update system continuously that just prints out the current WinitSettings seems to make this occur less frequently (occurs consistently while running the program, but sometimes doesn't occur on the next cargo run). That combined with the overall intermittent behavior has me wondering if this may be due to a system/update ordering issue/ambiguity?

[aloucks]

@zachbateman You can reproduce this with the drag_and_drop example or only your own code? I'm not able to reproduce with the example.

That combined with the overall intermittent behavior has me wondering if this may be due to a system/update ordering issue/ambiguity?

That seems plausible, but I thought that bevy now printed warnings when system order was ambiguous unless you opted in to it (e.g. https://docs.rs/bevy/latest/bevy/prelude/trait.IntoScheduleConfigs.html#method.ambiguous_with)