Skip to content
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.

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

Macos fires WindowEvent::Focused(false) on WinitWindow creation #2695

Closed
TimonPost opened this issue Feb 23, 2023 · 8 comments · Fixed by #2696
Closed

Macos fires WindowEvent::Focused(false) on WinitWindow creation #2695

TimonPost opened this issue Feb 23, 2023 · 8 comments · Fixed by #2696
Labels
A - needs repro waiting for a way to reproduce B - bug Dang, that shouldn't have happened DS - macos

Comments

@TimonPost
Copy link

TimonPost commented Feb 23, 2023

In this commit: b457329#diff-4803bb2335a17d700335730b9f62828e001faa602b9b894dff572422c737b78aR480 the author fires the Focused(false) event on macos window creation. It seems to be inconsistent with the other platforms.

In my case on macos I receive first Focused(true) and then Focused(false) when creating a window. The Focused(true) is caused by window_did_become_key and then Focused(false) is caused by the window init function queuing it when it is created.

On other platforms it seems like the focused boolean is automatically set to false upon creation without firing an event. This seems to create divergent behavior on different platforms as macos has an additional event now.

For now my fix is the following:

 WindowEvent::Focused(_focused) => {
        self.focused = winit.has_focus();
}

Sending an event on window creation creates unexpected behavior. Evenwhile my window is focused winit just informed me it isn't.

@TimonPost
Copy link
Author

cc: @amrbashir @kchibisov

@kchibisov
Copy link
Member

kchibisov commented Feb 23, 2023

In my case on macos I receive first Focused(true) and then Focused(false) when creating a window. The Focused(true) is caused by window_did_become_key and then Focused(false) is caused by the window init function queuing it when it is created.

So do you have Focused(false) for focused window?

@TimonPost
Copy link
Author

TimonPost commented Feb 23, 2023

Yes! When i print the output of Window::has_focus and the event WindowEvent::Focused(x) boolean it shows they are different. The event tells me my window is not focused while the function tells me it is focused. I think its a macos only problem as we did not get windows bugs reported.

@madsmtm madsmtm added B - bug Dang, that shouldn't have happened DS - macos labels Feb 23, 2023
kchibisov added a commit to kchibisov/winit that referenced this issue Feb 24, 2023
The synthetic focused event was queued after the real event was send
leading to focused issues on startup.

Fixes rust-windowing#2695.
kchibisov added a commit to kchibisov/winit that referenced this issue Feb 24, 2023
The synthetic focused event was queued after the real event was send
leading to focused issues on startup.

Fixes rust-windowing#2695.
@kchibisov
Copy link
Member

@TimonPost could you verify whether my patch changes anything for you? Because I can't repro the original issue you're having in the first place to begin with.

@kchibisov kchibisov added the A - needs repro waiting for a way to reproduce label Feb 24, 2023
kchibisov added a commit to kchibisov/winit that referenced this issue Feb 24, 2023
The synthetic focused event was queued after the real event was send
leading to focused issues on startup.

Fixes rust-windowing#2695.
@TimonPost
Copy link
Author

Will give it a try soon. Yes I found it hard to replicate the same behavior in an standalone app. We do have quite some complex setup of our window logic so many moving parts.

@kchibisov
Copy link
Member

Yeah, that would be nice, since my testing target is usually alacritty, and it works fine with the current logic we have.

kchibisov added a commit that referenced this issue Feb 27, 2023
The synthetic focused event was queued after the real event was send
leading to focused issues on startup.

Fixes #2695.
@TimonPost
Copy link
Author

I will still confirm the changes just need to get to work where I have a MacBook.

@kchibisov
Copy link
Member

Well, it was already confirmed, but yeah, sure.

kchibisov added a commit to kchibisov/winit that referenced this issue Mar 1, 2023
The synthetic focused event was queued after the real event was send
leading to focused issues on startup.

Fixes rust-windowing#2695.
kchibisov added a commit that referenced this issue Mar 2, 2023
The synthetic focused event was queued after the real event was send
leading to focused issues on startup.

Fixes #2695.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A - needs repro waiting for a way to reproduce B - bug Dang, that shouldn't have happened DS - macos
Development

Successfully merging a pull request may close this issue.

3 participants