Handle potential platform-specific `Window` mouse-enter/exit bugs gracefully #80187

Sauermann · 2023-08-02T20:27:14Z

Also replace DEV_ASSERT by ERR_FAIL.

followup to #67791
implement comment #67791 (comment)
based on #80156
fix #80335

Sauermann · 2023-08-03T11:31:46Z

After giving it some thought, I'm no longer sure, if ERR_FAIL is needed, because with this change, Window handles all possible cases.

akien-mga · 2023-08-03T11:48:13Z

scene/main/window.cpp

 		} break;
 		case DisplayServer::WINDOW_EVENT_MOUSE_EXIT: {
 			Window *root = get_tree()->get_root();
-			DEV_ASSERT(root->gui.windowmanager_window_over); // Exiting a window, while no window is hovered should never happen.
+			ERR_FAIL_NULL_MSG(root->gui.windowmanager_window_over, "Exiting a window, while no window is hovered should never happen.");


Suggested change

ERR_FAIL_NULL_MSG(root->gui.windowmanager_window_over, "Exiting a window, while no window is hovered should never happen.");

ERR_FAIL_NULL_MSG(root->gui.windowmanager_window_over, "Exiting a window while no window is hovered should never happen.");

But "should never happen" is still the kind of message that one would use for a DEV_ASSERT.

If it can be triggered by user code, and thus require an ERR_FAIL for graceful handling, then it does actually happen and the message should clarify what went wrong so that the user can fix it on their side.

Though I guess here the "user" can be a platform port that does things wrong in its window handling? So I guess it makes sense as is.

That is the question, that I try to wrap my head around.
If "user" is a engine-developer of platform code, then the error-message helps identifying an engine-problem.
if "user" is a game-developer, then the error-message has no benefit, because the game-developer can not address the problem.

In any case, I have accepted your code-change suggestion.

bruvzg

After giving it some thought, I'm no longer sure, if ERR_FAIL is needed, because with this change, Window handles all possible cases.

Probably not, I'm sure, if arrival of system move event messages is always guaranteed, and error won't be useful for users. It should be OK to simply ignore duplicate mouse enter/exit events.

bruvzg · 2023-08-03T12:20:20Z

scene/main/window.cpp

@@ -672,16 +672,21 @@ void Window::_event_callback(DisplayServer::WindowEvent p_event) {
 		case DisplayServer::WINDOW_EVENT_MOUSE_ENTER: {
 			_propagate_window_notification(this, NOTIFICATION_WM_MOUSE_ENTER);
 			Window *root = get_tree()->get_root();
-			DEV_ASSERT(!root->gui.windowmanager_window_over); // Entering a window while a window is hovered should never happen.
+			Window *previous_over = root->gui.windowmanager_window_over;


If mouse exit was not received, windowmanager_window_over might be an invalid pointer to the deleted Window (the same might happen in Viewport._update_mouse_over()). Maybe ObjectID should be stored instead.

Indeed I haven't thought about stale gui.windowmanager_window_over. Thanks for pointing me to this. I will investigate this and try to check situations, where this happens.

I have tried multiple ways to cause a crash on X11 based on stale gui.windowmanager_window_over

situations, that crashed without this fix

explicitly freeing (queue_free and free)

But I wasn't able to cause a crash. However I can't rule out, that it is possible to cause a crash this way.

Sauermann

Probably not, I'm sure, if arrival of system move event messages is always guaranteed, and error won't be useful for users. It should be OK to simply ignore duplicate mouse enter/exit events.

So for me this boils down to the following question:

Should platform-implementations be forced to adhere to the same behavior regarding send mouse-enter window-events or
should platform-implementations be allowed to be vague about mouse-enter window-events and catch all possible cases in the Window-class?

Personally I believe that the goal should be to align the behavior of all platform-implementations.

Sauermann · 2023-08-03T20:53:01Z

scene/main/window.cpp

@@ -672,16 +672,21 @@ void Window::_event_callback(DisplayServer::WindowEvent p_event) {
 		case DisplayServer::WINDOW_EVENT_MOUSE_ENTER: {
 			_propagate_window_notification(this, NOTIFICATION_WM_MOUSE_ENTER);
 			Window *root = get_tree()->get_root();
-			DEV_ASSERT(!root->gui.windowmanager_window_over); // Entering a window while a window is hovered should never happen.
+			Window *previous_over = root->gui.windowmanager_window_over;


Indeed I haven't thought about stale gui.windowmanager_window_over. Thanks for pointing me to this. I will investigate this and try to check situations, where this happens.

Sauermann · 2023-08-03T20:57:09Z

scene/main/window.cpp

 		} break;
 		case DisplayServer::WINDOW_EVENT_MOUSE_EXIT: {
 			Window *root = get_tree()->get_root();
-			DEV_ASSERT(root->gui.windowmanager_window_over); // Exiting a window, while no window is hovered should never happen.
+			ERR_FAIL_NULL_MSG(root->gui.windowmanager_window_over, "Exiting a window, while no window is hovered should never happen.");


That is the question, that I try to wrap my head around.
If "user" is a engine-developer of platform code, then the error-message helps identifying an engine-problem.
if "user" is a game-developer, then the error-message has no benefit, because the game-developer can not address the problem.

In any case, I have accepted your code-change suggestion.

clayjohn · 2023-08-08T10:42:23Z

Testing this locally. It fixes the crash caused by the dev assert. But every single time I navigate within the 3D viewport (RMB + mouse move for example) I get the "Entering a window while hovering it should never happen." error.

lawnjelly · 2023-08-08T10:48:52Z

Maybe a WARN_PRINT_ONCE might be better if it is spamming until the bug causing this is fixed?

Sauermann · 2023-08-08T10:50:42Z

Had the same idea about WARN_PRINT_ONCE. Will update the PR.

…cefully Also replace `DEV_ASSERT` by `WARN_PRINT_ONCE`.

akien-mga

Seems good as a stopgap solution.

akien-mga · 2023-08-08T15:05:48Z

Thanks!

Sauermann added enhancement topic:porting topic:gui labels Aug 2, 2023

Sauermann added this to the 4.2 milestone Aug 2, 2023

Sauermann requested a review from a team as a code owner August 2, 2023 20:27

lawnjelly approved these changes Aug 3, 2023

View reviewed changes

RandomShaper approved these changes Aug 3, 2023

View reviewed changes

Sauermann mentioned this pull request Aug 3, 2023

Fix crash on Windows when closing Window #80142

Merged

akien-mga reviewed Aug 3, 2023

View reviewed changes

bruvzg reviewed Aug 3, 2023

View reviewed changes

Sauermann force-pushed the fix-mouseover-error-handling branch from 81d2126 to b35f9de Compare August 3, 2023 21:33

Sauermann commented Aug 3, 2023

View reviewed changes

akien-mga mentioned this pull request Aug 4, 2023

GUI: Fix Tree performance regression by using cache #79325

Merged

akien-mga added bug crash labels Aug 4, 2023

Sauermann force-pushed the fix-mouseover-error-handling branch from b35f9de to a81a6aa Compare August 5, 2023 00:22

Sauermann mentioned this pull request Aug 8, 2023

Track hovered Window in DisplayServerX11 #80279

Merged

Handle potential platform-specific Window mouse-enter/exit bugs gra…

2f8673d

…cefully Also replace `DEV_ASSERT` by `WARN_PRINT_ONCE`.

Sauermann force-pushed the fix-mouseover-error-handling branch from a81a6aa to 2f8673d Compare August 8, 2023 11:06

akien-mga approved these changes Aug 8, 2023

View reviewed changes

akien-mga merged commit af722e2 into godotengine:master Aug 8, 2023

Sauermann deleted the fix-mouseover-error-handling branch August 9, 2023 10:31

This was referenced Aug 10, 2023

[Godot 4.2] File dialog crashes when adjusting filter array #80464

Closed

[Godot 4.2] Godot crash after adjusting value of ProgressBar through dragging #80465

Closed

[Godot 4.2] Godot crash when set step property of Godot to negative value #80466

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle potential platform-specific `Window` mouse-enter/exit bugs gracefully #80187

Handle potential platform-specific `Window` mouse-enter/exit bugs gracefully #80187

Sauermann commented Aug 2, 2023 •

edited

Loading

Sauermann commented Aug 3, 2023

akien-mga Aug 3, 2023

akien-mga Aug 3, 2023

Sauermann Aug 3, 2023

bruvzg left a comment

bruvzg Aug 3, 2023

Sauermann Aug 3, 2023

Sauermann Aug 6, 2023

Sauermann left a comment

Sauermann Aug 3, 2023

Sauermann Aug 3, 2023

clayjohn commented Aug 8, 2023 •

edited

Loading

lawnjelly commented Aug 8, 2023

Sauermann commented Aug 8, 2023

akien-mga left a comment

akien-mga commented Aug 8, 2023

	ERR_FAIL_NULL_MSG(root->gui.windowmanager_window_over, "Exiting a window, while no window is hovered should never happen.");
	ERR_FAIL_NULL_MSG(root->gui.windowmanager_window_over, "Exiting a window while no window is hovered should never happen.");

Handle potential platform-specific Window mouse-enter/exit bugs gracefully #80187

Handle potential platform-specific Window mouse-enter/exit bugs gracefully #80187

Conversation

Sauermann commented Aug 2, 2023 • edited Loading

Sauermann commented Aug 3, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bruvzg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sauermann left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clayjohn commented Aug 8, 2023 • edited Loading

lawnjelly commented Aug 8, 2023

Sauermann commented Aug 8, 2023

akien-mga left a comment

Choose a reason for hiding this comment

akien-mga commented Aug 8, 2023

Handle potential platform-specific `Window` mouse-enter/exit bugs gracefully #80187

Handle potential platform-specific `Window` mouse-enter/exit bugs gracefully #80187

Sauermann commented Aug 2, 2023 •

edited

Loading

clayjohn commented Aug 8, 2023 •

edited

Loading