Skip to content

[Bug]: Backspace right after a "+ " list shortcut in the composer deletes the marker #31988

Closed

Description

@efemaer

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

  1. Keep Settings > Rich text composer on (the default).
  2. In an empty composer, type + and then a space. The line turns into a bullet.
  3. Press Backspace.

The same happens with * and 1. .

Expected behavior

Backspace right after the shortcut undoes it and leaves the typed + as plain text, so you can go on and send + something. The composer already does this for > and # .

Actual behavior

The bullet and the typed + both disappear, and the line is empty. Cmd+Z gives back only +, and the next space makes a bullet again. With rich text on, a line that starts with a literal + can't be typed.

Impact

Minor bug or occasional failure

Version or commit

0.1.8-nightly.20261105.4234, and main @ 6577c6b

Environment

macOS 27.2, T3 Code (Nightly) desktop app

Workaround

Turn off Settings > Rich text composer, or paste the text.

Cause

The list item's Backspace handler in apps/web/src/composer-rich-text-doc.ts (backspaceAcrossList) replaces Tiptap's default Backspace. The default runs undoInputRule first, and the replacement does not, so the new item is lifted out of its list instead.

Activity

  1. OrdinaryPaki commented on Nov 7, 2026

    @OrdinaryPaki

    Should + stop being a list shortcut altogether?

    It isn't in the documented markers (- , 1. ), and people type + as a plus sign. #32005 makes it easy to undo, but the line still turns into a bullet first, and a draft with a + line reopens as a bullet.

    I have a small tested patch that removes + as a list marker when typing, reopening a draft and continuing a plain-mode list. - and * lists keep working, and the text sent to the agent doesn't change. It would conflict with the + test cases in #31989 and #32005, so I'd like your call before opening a PR.

    OK to open it?

  2. efemaer commented on Nov 7, 2026

    @efemaer
    Author

    Should + stop being a list shortcut altogether?

    @OrdinaryPaki that's actually a good point, and probably a product decision to be made by the maintainers.

    cc @juliusmarminge

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions