Skip to content

Verify event order#3710

Draft
madsmtm wants to merge 2 commits intomasterfrom
madsmtm/verify-event-order
Draft

Verify event order#3710
madsmtm wants to merge 2 commits intomasterfrom
madsmtm/verify-event-order

Conversation

@madsmtm
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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