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

Verify event order #3710

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Verify event order #3710

wants to merge 2 commits into from

Conversation

madsmtm
Copy link
Member

@madsmtm madsmtm commented May 27, 2024

The order that application handler methods are called in relation to each other is somewhat badly documented, and difficult to know for sure if correct. To remedy this, I've implemented a check that's enabled with debug assertions, and which logs if events are emitted in an unexpected order.

I went with using debug assertions, since I don't know of a better way to ensure that this will be tested, but there's of course a cost here in that if we don't catch all the issues, then downstream users will see these errors.

TODO:

  • Discuss whether the implemented check is the correct one.
  • Write better error message, with an explanation of where a user should report if they see it.
  • Check that this is the current behaviour on all platforms.
    • macOS
    • iOS
    • Android
    • Windows
    • X11
    • Wayland
    • Web

Once done, also fixes #3206.

@madsmtm madsmtm added B - bug Dang, that shouldn't have happened S - platform parity Unintended platform differences labels May 27, 2024
Base automatically changed from madsmtm/applicationhandler-mut to master May 29, 2024 09:51
@madsmtm madsmtm force-pushed the madsmtm/verify-event-order branch from 128fb21 to 14bedb6 Compare May 29, 2024 09:53
madsmtm added 2 commits May 29, 2024 14:28
When debug assertions are enabled, check that events are emitted in the
expected order, and if not, log an error.
@madsmtm madsmtm force-pushed the madsmtm/verify-event-order branch from 14bedb6 to 8968765 Compare May 29, 2024 12:28
Copy link
Member

@kchibisov kchibisov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The general idea is good, though, we'd need something to run all of that on CI in a crossplatform way.

But as for Suspended event, I'm still not sure whether we should emit it like that. Probably it won't hurt, but we must ensure that it's semantically the same place on all the platforms, right now I don't think it's the case.

Comment on lines +307 to +311
fn memory_warning(&mut self, event_loop: &ActiveEventLoop) {
// TODO: What states are allowed when receiving this?
self.inner.memory_warning(event_loop);
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's just a generic event which should be moved somewhere else, like to a separate trait. The ApplicationHandler today should represent the lifecycle of the event loop in the future, and real events should be on some other traits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B - bug Dang, that shouldn't have happened S - platform parity Unintended platform differences
Development

Successfully merging this pull request may close these issues.

2 participants