Other user's cursor shows over scrollable content.

[vivek-eraser]

This happens when the content is horizontally scrollable and other user is editing text. Screenshot attached below:

[alecgibson]

On top of this, the cursor doesn't move when scrolling the nested element

[alecgibson]

Honestly I'm not sure there's a lot we can do about this without a fundamental rethink on how this module works.

At the moment, it works by basically finding the range of the remote user's cursor, and just painting rectangles on top of Quill. This works fine for the most part, but as you can see, it breaks if the underlying content moves in an unexpected way.

This can even be a problem with Quill itself, and we have to make sure we hide Quill's overflow.

I'm not sure I'll have time to work on this (especially because we don't face this particular issue ourselves), but I'm happy to review any Pull Requests if you think you can fix it! As I say, I think it might require a fundamental rethink on how we draw cursors in general.

I've had some success in the past with a custom highlight blot, which actually sits in the Quill DOM itself (and therefore correctly gets moved around with the content). However, it's a bit hacky, and I think its behaviour can sometimes be a bit undefined if you're not careful:

/**
 * This is a special blot that is only ever represented in the DOM, and
 * never in the Delta. It's used for transient highlights, like search
 * highlighting.
 */
export default class HighlightBlot extends Inline {
  public static override tagName = 'MARK';
  public static override blotName = 'highlight';

  public static override create(value: any): HTMLElement {
    const node = super.create(value) as HTMLElement;
    node.classList.add(value.nodeClass);
    return node;
  }

  public static override formats(_node: Node): any {
    // Prevent this blot from showing up in the contents Delta
    return null;
  }

  public override unwrap(force?: boolean): void {
    // Prevent Quill from removing the blot, but allow us to manually override
    if (force) super.unwrap();
  }
}

There's an interesting change coming up in a W3C working draft: CSS Custom Highlight API Module, which — from a quick glance — I think would basically let us delete most of the code in this module!

However, it's currently not supported by any major browsers (but it has tickets open to track progress, which is positive):

• Chromium
• Firefox