TextStyle cannot be cleared when cursor is on new line

[C-Hess]

What’s the bug you are facing?

When you have your cursor on a new line and some text style is applied (either from the Font Family or Color extensions), you cannot clear out the text styles when the cursor is on a new line.

Which browser was this experienced in? Are any special extensions installed?

Chrome Version 109.0.5414.75 (Official Build) (64-bit)

Extensions:

• Text Style,
• Font Family,
• Color

How can we reproduce the bug on our side?

For either the font-family or color extensions, scroll down to the text editor demos:
https://tiptap.dev/api/extensions/font-family
https://tiptap.dev/api/extensions/color

1. Enter content in the editor, being sure to have either a font type selected or color active
2. Hit "Enter" to move the cursor to a new paragraph
3. Toggle off or unset the color or font type
4. Continue typing
5. Bug: the text styles are still applied

Can you provide a CodeSandbox?

No response

What did you expect to happen?

The text style should be removed from your stored marks even if the cursor is at the beginning of a new block

Anything to add? (optional)

I don't know why this issue only applies when the cursor is at the beginning of a new paragraph/block(?). It seems to be caused by weird interactions between .setMark("textStyle", { myAttr: null }) and .removeEmptyTextStyle().

Combining the two commands into a single custom transactional command seems to resolve this issue:

  chain()
      .command(({ tr: subCmdTr, state, commands }) => {
          const oldAttributes = getMarkAttributes(state, type);

          subCmdTr.addStoredMark(
              type.create({
                  ...oldAttributes,
                  ...{ fontSize: null },
              })
          );

          const newAttributes = getMarkAttributes(
              // Note the state.apply here. This may be part of the issue
              state.apply(subCmdTr),
              type
          );
          const hasStyles = Object.entries(newAttributes).some(
              ([, value]) => !!value
          );

          if (hasStyles) {
              return true;
          }

          return commands.unsetMark("textStyle");
      })
      .run();

Did you update your dependencies?

• Yes, I’ve updated my dependencies to use the latest version of all packages.

Are you sponsoring us?

• Yes, I’m a sponsor. 💖

[hkp1995]

I have the same problem. How can I solve it

[C-Hess]

@bdbch, I've already started work on this. However, I need some guidance here

It turns out there are two main factors that cause this behavior

Factor 1

We begin with the unset command of an extension that extends text-style. For example: font-family

https://github.com/ueberdosis/tiptap/blob/ccf05b04e3a2e2ee36c5bdac4d3b1a88bfe7a71d/packages/extension-font-family/src/font-family.ts#LL64C1-L67C17

Note that it first calls setMark then calls removeEmptyTextStyle

Factor 2

Chained commands fail to persist stored marks. Look at this code snippet; it looks like in between chained commands, we are resetting the transaction's stored marks based on what is in state:

https://github.com/ueberdosis/tiptap/blob/ccf05b04e3a2e2ee36c5bdac4d3b1a88bfe7a71d/packages/core/src/CommandManager.ts#LL123C1-L125C6

As a result, the storedMarks fields cannot be updated if you run more than one chained command.

Solution

The initial solution posted in this issue (to combine both commands into a single one) was able to resolve this issue because no subsequent commands are ran that would otherwise reset the stored mark.

Removing the logic that resets the transaction stored marks for chained commands also resolves the issue. This seems like the solution to go with, but I really would need to know what prompted the change to begin with. All I have to go off of is this commit that I'm struggling to find an associated PR/issue for:
532eaa4

[lzxlzxlzxl]

How to solve the problem？

[C-Hess]

@lzxlzxlzxl I'll submit a pull request with the above change sometime this week and hope to get a response about the solution through that