Skip to content

SD-1695 - add flag for text selection in viewing mode#1891

Open
mattConnHarbour wants to merge 3 commits intomainfrom
SD-1695
Open

SD-1695 - add flag for text selection in viewing mode#1891
mattConnHarbour wants to merge 3 commits intomainfrom
SD-1695

Conversation

@mattConnHarbour
Copy link
Contributor

No description provided.

@linear
Copy link

linear bot commented Jan 30, 2026

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b3b19fc0cd

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment on lines 4614 to +4616
if (hasPermissionOverride) return false;
// Allow selection visuals when allowSelectionInViewMode is enabled
if (this.#options.allowSelectionInViewMode) return false;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Keep view locked for input bridge in selection-only mode

Returning false here when allowSelectionInViewMode is set makes the rest of the presentation layer treat viewing mode as editable. In particular, #setupInputBridge() uses !this.#isViewLocked() to decide whether to forward key/composition/beforeinput events to the hidden editor, so selection-only mode now forwards IME/composition input and keyboard shortcuts even though Editor.setEditable(false) still marks the document read-only. The Editable extension only blocks beforeinput/keydown, not composition events, so IME input can still mutate the document in viewing mode. Consider keeping #isViewLocked() true for the input bridge (or adding a separate “selection-only” check) so selection visuals are allowed without re-enabling input forwarding.

Useful? React with 👍 / 👎.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#isViewLocked() returning false now also affects HeaderFooterSessionManager's #validateEditPermission() this could allow entering header/footer edit mode even though typing is blocked.

worth verifying that doesn't cause weird UI states, or adding a separate documentMode check there?

Copy link
Contributor

@caio-pizzol caio-pizzol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice one @mattConnHarbour!

wonder how we didn't catch this previously
ps. don't forget about allowing keyboard interactions as well

handleDoubleClick: () => !editor.options.editable && !editor.options.allowSelectionInViewMode,
handleTripleClick: () => !editor.options.editable && !editor.options.allowSelectionInViewMode,
// Always block keyboard input, paste, and drop when not editable
handleKeyDown: (_view, event) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this only allows Cmd+C

keyboard users or accessibility can't select (Shift+Arrow to extend, Cmd+A to select all) and/or navigate (arrows, Home/End).

Suggested change
handleKeyDown: (_view, event) => {
handleKeyDown: (_view, event) => {
if (!editor.options.editable) {
if (editor.options.allowSelectionInViewMode) {
// Allow navigation keys for selection
const isNavigationKey = [
'ArrowLeft', 'ArrowRight', 'ArrowUp', 'ArrowDown',
'Home', 'End', 'PageUp', 'PageDown'
].includes(event.key);
// Allow copy and select all
const isCopyOrSelectAll = (event.ctrlKey || event.metaKey) &&
['c', 'a'].includes(event.key.toLowerCase());
if (isNavigationKey || isCopyOrSelectAll) return false;
}
return true;
}
return false;
},

Comment on lines 4614 to +4616
if (hasPermissionOverride) return false;
// Allow selection visuals when allowSelectionInViewMode is enabled
if (this.#options.allowSelectionInViewMode) return false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#isViewLocked() returning false now also affects HeaderFooterSessionManager's #validateEditPermission() this could allow entering header/footer edit mode even though typing is blocked.

worth verifying that doesn't cause weird UI states, or adding a separate documentMode check there?

* - Click events are allowed for selection
* - But text input, keyboard shortcuts, paste, and drop remain blocked
*/
export const Editable = Extension.create({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no tests for the new flag (editable.js didn't have tests previously) - which makes it even more dangerous not knowing if this change could impact something

test add at least a unit test for the Cmd+C allowlist to prevent regressions

* Also returns false when allowSelectionInViewMode is enabled, allowing
* text selection while still blocking actual edits.
*/
#isViewLocked(): boolean {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: #isViewLocked() returning false while in viewing mode is a bit confusing - the name implies "is the view locked?" but it now means "should we hide selection?".

not worth changing now, but if this method grows more conditions might be worth splitting into #isInViewingMode() and #shouldBlockSelectionVisuals()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants