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

When should the window be created hidden? #255

Closed
marc2332 opened this issue Jun 24, 2023 · 8 comments
Closed

When should the window be created hidden? #255

marc2332 opened this issue Jun 24, 2023 · 8 comments
Labels
documentation Improvements or additions to documentation

Comments

@marc2332
Copy link

marc2332 commented Jun 24, 2023

Hey!

While I was working on accessibility support for Freya I noticed a weird behavior. The initial redraw request event never happens. So after some digging, I found out it only occurs when creating the Winit adapter

I have only tested this on Windows 11.

When creating the Winit adapter:
image

When not creating it :
image

I made a little reproduction example, the important line is this one

This issue is easy to fix by simply listening to the Init event of the eventloop and forcing a redraw request:

 Event::NewEvents(StartCause::Init) => {
    window.request_redraw();
}

But, is still not the expected behavior and I wonder if it could be causing other problems I am not aware of.

Anyway, nice job with accesskit 👏

@mwcampbell
Copy link
Contributor

Thanks for the report. Can you please specify which platform(s) this is happening on?

@marc2332
Copy link
Author

Thanks for the report. Can you please specify which platform(s) this is happening on?

I have only tested this in Windows 11, I can try in Linux if you want, but not MacOS as I don't have a Mac 😄

@mwcampbell
Copy link
Contributor

You need to create the window invisible, then create the adapter, then show the window. I'm sorry I didn't make that clear in the accesskit_winit docs. This is crucial on Windows, and possibly important on macOS as well.

@marc2332
Copy link
Author

You need to create the window invisible, then create the adapter, then show the window. I'm sorry I didn't make that clear in the accesskit_winit docs. This is crucial on Windows, and possibly important on macOS as well.

Ohh, I will try that, Linux works btw 😄

@DataTriny
Copy link
Member

Maybe we should panic if Window::is_visible() == Some(true) when initializing the adapter.

@marc2332
Copy link
Author

marc2332 commented Jun 24, 2023

You need to create the window invisible, then create the adapter, then show the window. I'm sorry I didn't make that clear in the accesskit_winit docs. This is crucial on Windows, and possibly important on macOS as well.

Yeah, that works ! ✨ You can close this issue if you want now 😄 But, maybe it could be clarified in the docs/examples.

@DataTriny DataTriny added the documentation Improvements or additions to documentation label Aug 20, 2023
@DataTriny DataTriny changed the title bug: accesskit_winit eats initial redraw request When should the window be created hidden? Aug 20, 2023
@DataTriny
Copy link
Member

Coming back to this, when exactly is it necessary to create the window hidden so that AccessKit can initialize properly?

  • accesskit_macos/Adapter
  • accesskit_macos/SubclassingAdapter
  • accesskit_unix/Adapter: N/A
  • accesskit_windows/Adapter: our example does it, but if I add WS_VISIBLE and remove the call to ShowWindow it seem to work without issues (tested with NVDA and Narrator on Windows 10). Can it be a timing issue under specific circumstances? If no, then we should document that UiaInitMarker must be created when handling WM_NCCREATE.
  • accesskit_windows/SubclassingAdapter: window must be hidden.

Once the above items are resolved, we should add a platform-specific note to accesskit_winit::Adapter::new.

@DataTriny
Copy link
Member

Solved by #278

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

3 participants