Inconsistency in handling 'cancel' modals #12434

New Issue

GiteaMirror · 2025-11-02T10:09:43-06:00

GiteaMirror commented

2025-11-02 10:09:43 -06:00

Originally created by @zokkis on GitHub (Feb 4, 2024).

Description

Some modals reset there state if canceled but most of the modals only close but persist any changes to the data.

To reproduce this

create Project
click 'New Column'
enter title
click 'cancel' in modal
click 'New Column' -> title is still there
the same is on like every other modal
- edit column
- Transfer Ownership
- Delete Wiki Data
- Delete This Repository
- Deploy Keys -> its not a modal
- Add Secret
- Manage SSH Keys -> its not a modal
- Manage GPG Keys -> its not a modal
on other modals the state gets reset
- Add Variable -> (still gets the 'stay on page' question)
- Submit review -> don't reset, but without 'stay on page' question

On some modals (like modals to create something) its ok and maybe good to have, but on other modals like edit/delete it should reset the state
The problem is, that the form has data and always ask to 'stay on page' because of unsaved data

Gitea Version

1.21.5

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

Git Version

No response

Operating System

Linux

How are you running Gitea?

I used the download, but it's also the same with own builds and on try.gitea.io

Database

MySQL/MariaDB

Originally created by @zokkis on GitHub (Feb 4, 2024). ### Description Some modals reset there state if canceled but most of the modals only close but persist any changes to the data. To reproduce this - create Project - click 'New Column' - enter title - click 'cancel' in modal - click 'New Column' -> title is still there - the same is on like every other modal - edit column - Transfer Ownership - Delete Wiki Data - Delete This Repository - Deploy Keys -> its not a modal - Add Secret - Manage SSH Keys -> its not a modal - Manage GPG Keys -> its not a modal - on other modals the state gets reset - Add Variable -> (still gets the 'stay on page' question) - Submit review -> don't reset, but without 'stay on page' question On some modals (like modals to create something) its ok and maybe good to have, but on other modals like edit/delete it should reset the state The problem is, that the form has data and always ask to 'stay on page' because of unsaved data ### Gitea Version 1.21.5 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots ![Screenshot from 2024-02-04 10-38-38](https://github.com/go-gitea/gitea/assets/72873130/65c6ecfd-3ade-490a-a1c4-d2d2cdca68ea) ### Git Version _No response_ ### Operating System Linux ### How are you running Gitea? I used the download, but it's also the same with own builds and on try.gitea.io ### Database MySQL/MariaDB

GiteaMirror added the type/bug label 2025-11-02 10:09:43 -06:00

GiteaMirror closed this issue

2025-11-02 10:09:43 -06:00

GiteaMirror commented

2025-11-02 10:09:44 -06:00

@zokkis commented on GitHub (Feb 4, 2024):

possible solutions are

maybe add type=reset to shared/modal_actions_confirm
web_src/js/features/common-global.js line 393 -> add form.reset() if the element has reset-class
- dont work with markdown-editor

or maybe refactor modals completely, because there is also a inconsistency in the styles

@zokkis commented on GitHub (Feb 4, 2024): possible solutions are - maybe add type=reset to shared/modal_actions_confirm - web_src/js/features/common-global.js line 393 -> add form.reset() if the element has reset-class - dont work with markdown-editor or maybe refactor modals completely, because there is also a inconsistency in the styles

GiteaMirror commented

2025-11-02 10:09:44 -06:00

@wxiaoguang commented on GitHub (Jun 21, 2025):

The "Rename Org" and "Delete Org" UI (new confirm modal) gets consistence behaviors now (by Rework delete org and rename org UI #34762 )

And most "modal form" also benefit from it, so many should have been fixed together.

In the future, we just need to refactor the legacy modals one by one by one if any modal still has inconsistent behavior.

The "Project column" modal also has been fixed (in 1.24)

Deploy Keys -> its not a modal
Manage SSH Keys -> its not a modal
Manage GPG Keys -> its not a modal

Since they are not modals, so the "cancel" only hides the panel, so maybe it's fine to keep the content there.

@wxiaoguang commented on GitHub (Jun 21, 2025): The "Rename Org" and "Delete Org" UI (new confirm modal) gets consistence behaviors now (by Rework delete org and rename org UI #34762 ) And most "modal form" also benefit from it, so many should have been fixed together. In the future, we just need to refactor the legacy modals one by one by one if any modal still has inconsistent behavior. ---- The "Project column" modal also has been fixed (in 1.24) ---- * Deploy Keys -> its not a modal * Manage SSH Keys -> its not a modal * Manage GPG Keys -> its not a modal Since they are not modals, so the "cancel" only hides the panel, so maybe it's fine to keep the content there.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12434