Sometimes throwing an error and yielding to browser gives desired behavior - can we do this a safer way?

Some tasks are exceedingly complex to achieve in ProseMirror but will just work if we throw an error. IS there some way we can leverage the browser behavior without throwing an error? I understand this is an escape hatch if it’s supported, but it’s better than spending a week to build a feature that’s already built - I just don’t want to need to throw an error to achieve it.

False yields to the next handler. True stops the handlers from firing. But there’s no way to leverage the browser intentionally it seems.

It would help a lot if you would tell me what kind of task/event you are talking about.

Thanks for your reply @marijn. Like if I wanted to allow the browser to handle a backspace event rather than ProseMirror - for example at the start of a codeblock which normally would unwrap the entire codeblock. If you let Chrome handle it, it doesn’t unwrap the entire block. But I guess the bigger issue with that is that yielding to the browser would make it so that ProseMirror wouldn’t know how to undo the operation, right?

Thanks again for reading.

You really don’t want to rely on the native browser behavior for something like backspace. It’ll be inconsistent between platforms, schema-unaware, and often just plain broken. The recommended way to adjust the way backspace behaves is, indeed, to bind a custom command to the key.

If we know the application will only run in such and such environment it seemed a possibility. I verified the browser behavior is what we desire (and I know it could change someday.)

Advisability aside, is there any escape hatch to do things this way? And even if we did I assume it would break history.

It should not break history. But no, there’s no escape hatch for it.

1 Like