langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-20 09:10:05 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Feature request: Configurable Enter/Shift+Enter behavior in embedded chat input #22214

New Issue
Open
opened 2026-02-21 20:16:11 -05:00 by yindo · 4 comments
yindo commented 2026-02-21 20:16:11 -05:00
Owner
Copy Link
Copy Source

Originally created by @mandu001 on GitHub (Feb 12, 2026).

Originally assigned to: @mandu001, @agent-steven on GitHub.

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

We are embedding Dify Chat (Cloud) into a customer website for end users in Japan.

Currently, the chat input behavior is "Enter = send", which frequently causes accidental sending because many Japanese users expect "Enter = newline" when composing multi-line messages (especially with Japanese IME). This is a UX issue for production use and increases support burden.

Steps / Scenario:

  1. Embed Dify Chat into a website (Cloud embedded chat).
  2. Type a multi-line message (Japanese or English).
  3. Press Enter expecting a newline.
  4. The message is sent immediately.

Actual behavior:

  • Enter sends the message.

Expected behavior:

  • Provide a configurable option so we can use: "Enter = newline" and "Shift+Enter = send" (or a toggle to switch keybindings).
  • Ideally keep the current default behavior and add an optional setting.

2. Additional context or comments

Environment:

  • Dify: Cloud
  • Usage: Embedded chat on a customer website (production)
  • Users: Japanese end users
  • Browser/OS: Chrome on Windows/macOS (also mobile browsers)
  • Input method: Japanese IME (important)

Notes / Suggestions:

  • Please ensure IME composition does not trigger sending unexpectedly (e.g., when pressing Enter to confirm composition). Handling event.isComposing / composition events may be necessary.
  • It would be great to support either:
    • a UI toggle in settings, and/or
    • an embed parameter to configure key behavior.
  • Desired key behavior: Enter = newline, Shift+Enter = send.

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
Originally created by @mandu001 on GitHub (Feb 12, 2026). Originally assigned to: @mandu001, @agent-steven on GitHub. ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] Please do not modify this template :) and fill in all the required fields. ### 1. Is this request related to a challenge you're experiencing? Tell me about your story. We are embedding Dify Chat (Cloud) into a customer website for end users in Japan. Currently, the chat input behavior is "Enter = send", which frequently causes accidental sending because many Japanese users expect "Enter = newline" when composing multi-line messages (especially with Japanese IME). This is a UX issue for production use and increases support burden. Steps / Scenario: 1) Embed Dify Chat into a website (Cloud embedded chat). 2) Type a multi-line message (Japanese or English). 3) Press Enter expecting a newline. 4) The message is sent immediately. Actual behavior: - Enter sends the message. Expected behavior: - Provide a configurable option so we can use: "Enter = newline" and "Shift+Enter = send" (or a toggle to switch keybindings). - Ideally keep the current default behavior and add an optional setting. ### 2. Additional context or comments Environment: - Dify: Cloud - Usage: Embedded chat on a customer website (production) - Users: Japanese end users - Browser/OS: Chrome on Windows/macOS (also mobile browsers) - Input method: Japanese IME (important) Notes / Suggestions: - Please ensure IME composition does not trigger sending unexpectedly (e.g., when pressing Enter to confirm composition). Handling event.isComposing / composition events may be necessary. - It would be great to support either: - a UI toggle in settings, and/or - an embed parameter to configure key behavior. - Desired key behavior: Enter = newline, Shift+Enter = send. ### 3. Can you help us with this feature? - [x] I am interested in contributing to this feature.
yindo added the 💪 enhancementgood first issue labels 2026-02-21 20:16:11 -05:00
yindo commented 2026-02-21 20:16:11 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Feb 12, 2026):

This sounds interesting.

@crazywoola commented on GitHub (Feb 12, 2026): This sounds interesting.
yindo commented 2026-02-21 20:16:11 -05:00
Author
Owner
Copy Link
Copy Source

@agent-steven commented on GitHub (Feb 12, 2026):

Hi! I'd like to work on this.

My plan:

  1. Add a configurable Enter/Shift+Enter behavior toggle in the embedded chat settings
  2. Handle IME composition events properly (check event.isComposing / compositionend) to prevent accidental sends during Japanese/Korean/Chinese input
  3. Support both a UI toggle in chat settings and an embed parameter for configuration
  4. Default behavior remains unchanged (Enter = send) for backward compatibility

I'll submit a PR with a demo shortly.

@agent-steven commented on GitHub (Feb 12, 2026): Hi! I'd like to work on this. My plan: 1. Add a configurable Enter/Shift+Enter behavior toggle in the embedded chat settings 2. Handle IME composition events properly (check `event.isComposing` / `compositionend`) to prevent accidental sends during Japanese/Korean/Chinese input 3. Support both a UI toggle in chat settings and an embed parameter for configuration 4. Default behavior remains unchanged (Enter = send) for backward compatibility I'll submit a PR with a demo shortly.
yindo commented 2026-02-21 20:16:11 -05:00
Author
Owner
Copy Link
Copy Source

@mandu001 commented on GitHub (Feb 13, 2026):

Thanks for picking this up and opening the PR! 🙏
The plan matches what we need. Our main requirement is for the Cloud embedded chat used by Japanese end users: Enter = newline / Shift+Enter = send as an optional toggle, while keeping the default unchanged for backward compatibility.
IME handling (avoiding sends during composition) is especially important. Happy to test and provide feedback once there’s a preview/build.

@mandu001 commented on GitHub (Feb 13, 2026): Thanks for picking this up and opening the PR! 🙏 The plan matches what we need. Our main requirement is for the Cloud embedded chat used by Japanese end users: Enter = newline / Shift+Enter = send as an optional toggle, while keeping the default unchanged for backward compatibility. IME handling (avoiding sends during composition) is especially important. Happy to test and provide feedback once there’s a preview/build.
yindo commented 2026-02-21 20:16:11 -05:00
Author
Owner
Copy Link
Copy Source

@agent-steven commented on GitHub (Feb 13, 2026):

Thanks @mandu001! That aligns exactly with the PR I submitted: #32300

It supports sendOnEnter=false (Enter = newline, Shift+Enter = send) via both the embed config and URL parameter, with the default unchanged. IME composition handling is preserved so accidental sends during Japanese input won't happen.

Happy to adjust anything based on your testing feedback!

@agent-steven commented on GitHub (Feb 13, 2026): Thanks @mandu001! That aligns exactly with the PR I submitted: #32300 It supports `sendOnEnter=false` (Enter = newline, Shift+Enter = send) via both the embed config and URL parameter, with the default unchanged. IME composition handling is preserved so accidental sends during Japanese input won't happen. Happy to adjust anything based on your testing feedback!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label good first issue 💪 enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#22214
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?