[Bug]: InputRules seem not to fire in 2.5.5

[Nantris]

Affected Packages

core

Version(s)

2.5.5

Bug Description

After upgrading from 2.5.4 to 2.5.5 several tests broke here. I took a look and it seems breakpoints inside of input rules are no longer being hit. Presumably it's not all input rules since only a few tests broke. Most of the broken tests seem to relate to lists.

Example input rule which no longer applies:

wrappingInputRule({
  find: taskItemRegex,
  type: this.type,
  getAttributes: match => ({
    checked: match.at(-1)?.toLowerCase() === 'x',
  }),
}),

Browser Used

Chrome

Code Example URL

No response

Expected Behavior

InputRule behavior is unchanged from 2.5.4

Additional Context (Optional)

We have a custom parseHTML so it seems unlikely to me that this PR broke it: b47df57

At the same time, none of the others jump out to me as obvious causes either.

Dependency Updates

• Yes, I've updated all my dependencies.

[nperez0111]

@Nantris I don't see anything that would be different here for input rules between these versions: @tiptap/vue-3@2.5.4...v2.5.5

2.5.5 was mostly around vue 3 performance updates, are you using vue-3?

The only other code change could have been: #5321

I would need more information to help you out here

[nperez0111]

Is it just the one input rule that is not applying? Could your parseHTML not be applying? Maybe you have the task list extension installed twice? I don't know what could be breaking you here

[nperez0111]

Any update on this @Nantris? I've also addressed a couple more bugs since so may be worth upgrading

[Nantris]

@nperez0111 thanks for the ping on this.

I tried 2.5.7 but the issue persisted.

I was able to identify the problem commit: 4cca3826950176b6d9981cdc6e1e9b654f696319 but heck if I know why.

None of the affected rules seem to have anything to do with atom nodes. Unfortunately I'm finding it impossible to set breakpoints or logpoints in the .ts files, maybe due to some problem in the sourcemaps, so I can't readily provide as much information as I'd like (eg why this is making any difference in a document without any atom nodes present.)

Via manually editing the file in node_modules I was able to at least determine the behavior difference:

• 2.5.5 (Problem): {textBefore: '[x]abc'}
• 2.5.4 (No problem): {textBefore: '[x]'}

In both cases the caret was in the position immediately after the [x]| (pipe character representing caret), so the abc should not be considered part of the textBefore.

Thanks again for the great work you're doing @nperez0111!

[nperez0111]

Thanks for hunting this down @Nantris I found the bug & will be resolved by: #5407

[nperez0111]

Should be resolved already with v2.5.9

[Nantris]

Confirmed resolved; forgot to close. Thanks for your great work @nperez0111!