[GH-ISSUE #13800] feat: confirmation on deleting chat with shift key pressed #17037

New Issue

GiteaMirror · 2026-04-19T22:49:02-05:00

GiteaMirror commented

2026-04-19 22:49:02 -05:00

Originally created by @ibuki2003 on GitHub (May 12, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/13800

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

If the Shift key is held down, the delete chat button is directly accessible without the menu, and pressing it deletes the data immediately without any confirmation. While this shortcut improves efficiency, the absence of a confirmation dialog increases the risk of accidental data deletion.

Desired Solution you'd like

I would like to request an option to configure the deletion behavior such that users can choose between:

Always requiring a confirmation dialog before deletion, regardless of whether the delete button is accessed via the menu or directly with the Shift key
Keeping the current behavior where deletion via the Shift-key direct button bypasses confirmation

This configuration would allow users to balance their preferences for safety and speed, reducing unintended data loss without hindering efficient workflows.

Alternatives Considered

No response

Additional Context

No response

Originally created by @ibuki2003 on GitHub (May 12, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/13800 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description If the Shift key is held down, the delete chat button is directly accessible without the menu, and pressing it deletes the data immediately without any confirmation. While this shortcut improves efficiency, the absence of a confirmation dialog increases the risk of accidental data deletion. ### Desired Solution you'd like I would like to request an option to configure the deletion behavior such that users can choose between: - Always requiring a confirmation dialog before deletion, regardless of whether the delete button is accessed via the menu or directly with the Shift key - Keeping the current behavior where deletion via the Shift-key direct button bypasses confirmation This configuration would allow users to balance their preferences for safety and speed, reducing unintended data loss without hindering efficient workflows. ### Alternatives Considered _No response_ ### Additional Context _No response_

GiteaMirror closed this issue

2026-04-19 22:49:03 -05:00

GiteaMirror commented

2026-04-19 22:49:04 -05:00

@Classic298 commented on GitHub (May 12, 2025):

If the Shift key is held down, the delete chat button is directly accessible without the menu, and pressing it deletes the data immediately without any confirmation. While this shortcut improves efficiency, the absence of a confirmation dialog increases the risk of accidental data deletion.

This is intentional. This is for quick deletion.

If you do not want this, do not press SHIFT.

Deleting a chat requires pressing the three dots to expand the menu > Delete > [Popup] Confirm Deletion

@Classic298 commented on GitHub (May 12, 2025): > If the Shift key is held down, the delete chat button is directly accessible without the menu, and pressing it deletes the data immediately without any confirmation. While this shortcut improves efficiency, the absence of a confirmation dialog increases the risk of accidental data deletion. This is intentional. This is for quick deletion. If you do not want this, do not press SHIFT. Deleting a chat requires pressing the three dots to expand the menu > Delete > [Popup] Confirm Deletion

GiteaMirror commented

2026-04-19 22:49:05 -05:00

@tjbck commented on GitHub (May 12, 2025):

Intended behaviour.

@tjbck commented on GitHub (May 12, 2025): Intended behaviour.

GiteaMirror commented

2026-04-19 22:49:05 -05:00

@ibuki2003 commented on GitHub (May 12, 2025):

Thank you for your quick response.

However, I would like to raise two concerns for your consideration:

Shift key detection reliability
In my experience, the detection whether the Shift key is pressed or not can be unreliable due to factors such as tab switching or focus changes, which may cause the system to incorrectly assume the Shift key is held down. This led to an accidental deletion in my case.
I understand that, since the implementation relies on key event detection, it may be inherently difficult to completely eliminate such issues, which might make fixing this as a bug challenging.
If you think it is appropriate, I would like to file this as a bug report, but I would appreciate your guidance on whether this falls within the scope of a bug or a usage limitation.
Safety of a deletion operation without undo or confirmation
Even if the quick deletion shortcut is intentional, allowing a dangerous, non-reversible operation triggered by a single modifier key increases the risk of accidental data loss. From a usability and safety perspective, I believe it would be safer to require at least a confirmation dialog or provide an undo mechanism for such deletions.
In my opinion, introducing a simple configuration option (a switch) to enable or disable the confirmation dialog for Shift-key-enabled deletion would be sufficient.
If such a feature is acceptable, I would be happy to contribute by creating a pull request to add this functionality.

I hope these points can be taken into account to enhance the robustness and safety of the deletion feature.

@ibuki2003 commented on GitHub (May 12, 2025): Thank you for your quick response. However, I would like to raise two concerns for your consideration: 1. **Shift key detection reliability** In my experience, the detection whether the Shift key is pressed or not can be unreliable due to factors such as tab switching or focus changes, which may cause the system to incorrectly assume the Shift key is held down. This led to an accidental deletion in my case. I understand that, since the implementation relies on key event detection, it may be inherently difficult to completely eliminate such issues, which might make fixing this as a bug challenging. If you think it is appropriate, I would like to file this as a bug report, but I would appreciate your guidance on whether this falls within the scope of a bug or a usage limitation. 2. **Safety of a deletion operation without undo or confirmation** Even if the quick deletion shortcut is intentional, allowing a dangerous, non-reversible operation triggered by a single modifier key increases the risk of accidental data loss. From a usability and safety perspective, I believe it would be safer to require at least a confirmation dialog or provide an undo mechanism for such deletions. In my opinion, introducing a simple configuration option (a switch) to enable or disable the confirmation dialog for Shift-key-enabled deletion would be sufficient. If such a feature is acceptable, I would be happy to contribute by creating a pull request to add this functionality. I hope these points can be taken into account to enhance the robustness and safety of the deletion feature.

GiteaMirror referenced this issue

2026-04-20 00:19:05 -05:00

[GH-ISSUE #17037] issue: PDF download is image-only (text cannot be selected or copied) #18148

GiteaMirror referenced this issue

2026-04-25 07:34:29 -05:00

[GH-ISSUE #17037] issue: PDF download is image-only (text cannot be selected or copied) #33677

GiteaMirror referenced this issue

2026-05-05 20:08:00 -05:00

[GH-ISSUE #17037] issue: PDF download is image-only (text cannot be selected or copied) #56814

Sign in to join this conversation.