Confirmation prompts are accepted even if "Cancel" is clicked
OS & Hardware Linux + Docker
Version 0.36.0
Describe the bug User account is deleted after pressing "Cancel my account" even if "Cancel" is clicked in the confirmation dialog.
To Reproduce
- Use Google Chrome
- Go to user settings
- Click "Cancel my account"
- Click "Cancel" in the confirmation dialog
- Account gets deleted anyway
Expected behavior Account is not deleted
Logs
User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT $2 [["id", 19], ["LIMIT", 1]]
TRANSACTION (0.1ms) BEGIN
<a bunch of select statements omitted>
User Destroy (0.7ms) DELETE FROM "users" WHERE "users"."id" = $1 [["id", 19]] TRANSACTION (7.7ms) COMMIT
{"method":"DELETE","path":"/users","format":"turbo_stream","controller":"Users::RegistrationsController","action":"destroy","status":303,"allocations":26164,"duration":35.62,"view":0.0,"db":11.42,"location":"https://my.domain/"}
Additional context
The following happens in Google Chrome (likely all chromium-based browsers):
After clicking the "Cancel my account" button, POST /users request with _method=delete&authenticity_token=xxx body begins. It stays in (pending) state in the devtools until any button in the dialog is clicked, however the account is already deleted at that point (see logs above). If you click cancel, the request shows as completed with 303 status in the browser. If you click OK, the request also shows as completed, but an additional POST /users?_method=delete request with _method=delete body is sent (the server responds with redirect to /users/sign_in as the user is already deleted).
Interestingly, in Firefox the first request always gets cancelled with NS_BINDING_ABORTED for some reason, but there still is a chance that it reaches the server and the account will be deleted.
The same seems to happen with other confirmation dialogs too (tested on the Immich import prompt)