document restrictions not enforced

[johanneswilm]

Given a schema declaration which contains:

doc: {type: Doc, content: "title subtitle authors abstract keywords body"},
title: {type: Title, content: "text*"},
subtitle: {type: Subtitle, content: "text*"},
authors: {type: Authors, content: "text*"},
abstract: {type: Abstract, content: "block+"},
keywords: {type: Keywords, content: "text*"},
body: {type: Body, content: "block+"},
[...]

Do:

1. select part of the contents of the title node and parts of the subtitle node.
2. Hit "backspace"

Expected behavior: No change as schema declaration prevents title and subtitle node from merging.

Observed behavior: Title and subtitle nodes are merged and two JavaScript errors are thrown: "Uncaught RangeError: Maximum call stack size exceeded" and "Uncaught Error: Invalid content for node doc"

[marijnh]

I was able to construct a test case that created a similar error. Please see whether attached patch helps for you.

The intended behavior is not for nothing to happen, in cases like this, but rather for something as close as possible to the regular behavior to happen, without breaking the content restrictions. In this case, the title and subtitle will be joined into a title, and a new empty subtitle will be created.

(Yes, it's magic. But it's needed to make copy-paste useable in schemas like this. Also, it can be pretty neat, in terms of user interface, to be able to apply classical wysiwyg-style manipulation even in semantically constrained content.)

[johanneswilm]

@marijnh Now it works if I select part of the title and part of the subtitle and hit backspace (the result being as you described). However, if I put the caret at the very start of the subtitle (collapsed), and hit backspace, it still throws a "Invalid content for node doc" error.

The magic is likely ok in this particular case. But I'm not sure this will always be true. And a rule such as "If change is forbidden, nothing happens" is a lot easier to understand than "the editor will try to patch it together in some reasonable manner". So, I'm skeptical for now, but if I don't find any concrete issues with this approach, I can be convinced.

[marijnh]

Yep, that was a different bug. As I mentioned in the forum thread, this causes potential failure cases to pop up everywhere, and it might be a few iterations before I've caught them all. Attached patch should help with the issue you describe.

[johanneswilm]

Yep, that worked.

it might be a few iterations before I've caught them all.

Understood. Probably better I file new issues if I find more then. As it is, this particular issue has been fixed. Thanks!