fix: Prevent Enter during IME compose in submission dialogs

[neverether]

Description

When typing with an IME (e.g. Japanese, Chinese, Korean), pressing Enter to confirm a character conversion immediately submitted dialogs. For example, in the "New Space" dialog, typing tesuto and pressing Enter to accept the テスト conversion created the space right away, before the user could finish typing the intended name.

This happens because the keydown that confirms an IME composition is delivered to the page as a regular Enter keydown on macOS (Windows IMEs swallow it, so the bug only manifests on macOS), and the Enter handlers never checked KeyboardEvent.isComposing.

Changes:

• Added an isComposingEvent helper to web-pkg that treats an event as part of a composition session when isComposing is set, or when keyCode is 229 for browsers that fire the composition-ending keydown with isComposing already unset (e.g. Safari).
• Guarded the Enter-to-confirm handlers with it:
  • OcModal input (covers New Space, New Folder, New File, Rename, Edit Description and every other hasInput modal) — check inlined here since the design system cannot import web-pkg
  • SetLinkPasswordModal — browsers suppress IMEs on type="password" inputs, but the field's "show password" toggle switches it to type="text", where the IME is active and the same premature submit occurs
  • FileNameModal (external app)
  • CreateShortcutModal drop selection
• Added regression unit tests for the helper and the guarded components.

Before:
https://github.com/user-attachments/assets/674bca8a-09b0-4229-9e5c-2197616386d8

After:
https://github.com/user-attachments/assets/cb3badf9-cb47-4fc9-ac9e-66be34f2b286

Note: This PR also covers the Password Edit dialog – there may be a potential oversight in this area. When typing in a password with the password mask on (input type = password), IMEs and blocked and we're limited to safe alphanumeric password input. However when the mask is off (clicking the eyeball icon, the type = text), it's now possible to utilize the IME to input unicode. I'm not sure this is the intended policy and can cause passwords with unintended values/inputs. This might need addressing, but I'm uncertain of the intent here.

Related Issue

• Fixes Japanese and other East Asian Languages IME input can prematurely submit forms #2646

How Has This Been Tested?

• test environment: local docker compose setup, macOS Chrome with the Japanese IME
• test case 1: "+ New" → Space, type tesuto, press Enter to confirm the テスト conversion → the dialog no longer submits; a subsequent plain Enter submits as before. Same for rename and other input dialogs.
• test case 2: new unit tests — Enter keydown with isComposing: true or keyCode === 229 does not emit confirm, plain Enter does.

Types of changes

• Bugfix
• Enhancement (a change that doesn't break existing code or deployments)
• Breaking change (a modification that affects current functionality)
• Technical debt (addressing code that needs refactoring or improvements)
• Tests (adding or improving tests)
• Documentation (updates or additions to documentation)
• Maintenance (like dependency updates or tooling adjustments)

[JammingBen]

Thanks for looking into this.

I guess the same is missing in OcSearchBar.vue and SearchBar.vue, or did you leave these out intentionally?

[neverether]

@JammingBen Thanks for reviewing so quickly.

I guess the same is missing in OcSearchBar.vue and SearchBar.vue, or did you leave these out intentionally?

I did spot those and the issue does manifest there as well; however in the case of the search bar the unintentional submit doesn't seem to have negative consequences - the focus is still in the input so the user can continue typing, it'll just return results early like a faux debounced search.

If you have a preference to keep it entirely consistent across those as well, I'll bundle it in.

[JammingBen]

I did spot those and the issue does manifest there as well; however in the case of the search bar the unintentional submit doesn't seem to have negative consequences - the focus is still in the input so the user can continue typing, it'll just return results early like a faux debounced search.

Sounds reasonable, I'm fine with keeping it as it is then.

[neverether]

@JammingBen Have addressed your comment; moving the helper to design-system required an update to peerDeps for type resolution, let me know if that matches convention correctly.

[JammingBen]

Looks good, thanks again!