Skip to content

Conversation

mj-kiwi
Copy link
Contributor

@mj-kiwi mj-kiwi commented Oct 14, 2025

When the confirmation dialog is closed (result is null), the promise should resolve with false to indicate that the user did not grant confirmation. This adds proper handling for the dialog closure scenario and includes a corresponding test case.

Description

Related issues

Fixes:

Manual testing steps

  1. Go to this page...

Screenshots/Recordings

Before

Screen.Recording.2025-10-14.at.2.49.11.PM.mov

After

Screen.Recording.2025-10-14.at.2.44.23.PM.mov

Pre-merge author checklist

Pre-merge reviewer checklist

  • I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
  • I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

Note

Handle dialog closure by resolving false and refine cleanup/unbind logic; add test coverage for closure behavior.

  • Core (packages/gator-permissions-snap/src/core/confirmation.tsx):
    • Handle snap_dialog returning null (dialog closed) by cleaning up without resolving the interface and resolving false.
    • Refactor cleanup to accept resolveInterface flag and safely unbind handlers with try/finally; centralize unbind logic in #unbindHandlers.
  • Tests (packages/gator-permissions-snap/test/core/confirmation.test.ts):
    • Add test to assert resolving false when dialog is closed and that event listeners are unbound.

Written by Cursor Bugbot for commit 4261d0f. This will update automatically on new commits. Configure here.

…on flow

When the confirmation dialog is closed (result is null), the promise should resolve with false
to indicate that the user did not grant confirmation. This adds proper handling for
the dialog closure scenario and includes a corresponding test case.

This change ensures that the confirmation dialog properly handles the case where
the user closes the dialog without making a decision, returning false instead of
undefined or other unexpected values. The test case verifies this behavior.
@mj-kiwi mj-kiwi requested a review from a team as a code owner October 14, 2025 01:54
cursor[bot]

This comment was marked as outdated.

@mj-kiwi mj-kiwi requested a review from MoMannn October 14, 2025 22:14
// cleanup can't be defined before the click handlers, so cannot be const
// eslint-disable-next-line prefer-const
let cleanup: () => Promise<void>;
let cleanup: (resolveInterface?: boolean) => Promise<void>;
Copy link
Contributor

Choose a reason for hiding this comment

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

Not strictly related to the changes in this PR, but I'm wondering whether the cleanup function needs to be anonymous, or whether it can be a private instance method.

I think previously the unbind handlers were consts, so were within the closure in which anonymous cleanup function.

We can only have one interface open at any given time, so this.#interfaceId and this.#unbindHandlers should be sufficient for the cleanup function.

WDYT?

Maybe I'm missing something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants