Fix: paste-while-typing bug and remove copyNodeEnabled feature flag - #219
Fix: paste-while-typing bug and remove copyNodeEnabled feature flag#219priyanshu6238 wants to merge 1 commit into
Conversation
…rsion to 1.43.0-15
|
Important Review available on request
Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
priyanshu6238
changed the title
| return; | ||
| } | ||
| if (this.props.pasteNode) { | ||
| event.preventDefault(); |
There was a problem hiding this comment.
This is the one I'd most like changed. pasteNode is a bound thunk from Flow.tsx:438, so if (this.props.pasteNode) on line 132 is always true in the real app and guards nothing. preventDefault() then fires, and only afterwards does the thunk check localStorage[CLIPBOARD_KEY] and bail if it's empty (thunks.ts:1292-1293).
So every Ctrl/Cmd+V outside an /<textarea> cancels the browser's native paste — including when the editor has nothing to paste at all. Anything the allow-list doesn't recognise loses paste for zero benefit.
Please read the clipboard key first and only preventDefault() when a node paste will actually happen. That reorder turns every present and future gap in the guard from "paste is broken" into "nothing happens" — which is the difference between a guard that has to be perfect and one that only has to be good. Given this bug shipped once already, that safety margin is worth more than the guard itself.
| } | ||
|
|
||
| const activeTag = active?.tagName?.toLowerCase(); | ||
| if (activeTag === 'input' || activeTag === 'textarea') { |
There was a problem hiding this comment.
The allow-list is input/textarea only — no isContentEditable. Not a live bug today: I checked and neither floweditor's src nor temba uses contenteditable. But this listener is on document, and floweditor runs inside the glific-frontend page, which has Lexical/Quill editors and its own dialogs on the same document. Any host-side rich-text field focused while the canvas is mounted gets its paste swallowed.
active instanceof HTMLElement && active.isContentEditable is one line and future-proofs both repos.
| } | ||
| } | ||
|
|
||
| if ((event.ctrlKey || event.metaKey) && event.key === 'v') { |
There was a problem hiding this comment.
event.key === 'v' is case-sensitive — with Caps Lock on or Shift held the key is 'V', so Ctrl+Shift+V and Ctrl+V-with-capslock don't paste a node. This fails in the safe direction (no preventDefault), so it's not urgent, just inconsistent. event.key.toLowerCase() === 'v' if you want it.
2 participants
Summary
temba-*elements).document.activeElementstops at the shadow host instead of resolving to the real focused element, soCanvas.handleKeyDownnow walksshadowRoot.activeElementrecursively to find the true focused node before deciding whether to treat the keystroke as a paste.copyNodeEnabledconfig flag and all plumbing for it (FlowEditorConfig,EditorState,mapStateToPropsinAction.tsx/Node.tsx,components/index.tsx, test config) — copy is now always available rather than gated behind a host-provided flag.