Looks like this is the most common VisualEditor error in our logging: https://logstash.wikimedia.org/goto/cc220cded23ed5a7c9ff42b7e700624c

Digging into one of these traces, the error originates from:

if ( !selection.isNativeCursor() || this.focusedBlockSlug ) {
	// Model selection is an emulated selection (e.g. table). The view is certain to
	// match it already, because there is no way to change the view selection when
	// an emulated selection is showing.
	return false;
}
modelRange = selection.getModel().getRange();
if ( !force && this.$attachedRootNode.get( 0 ).contains(
	this.nativeSelection.focusNode
) ) {
	// See whether the model range implied by the DOM selection is already equal to
	// the actual model range. This is necessary because one model selection can
	// correspond to many DOM selections, and we don't want to change a DOM
	// selection that is already valid to an arbitrary different DOM selection.
	var impliedModelRange = new ve.Range(
		ve.ce.getOffset(
			this.nativeSelection.anchorNode,
			this.nativeSelection.anchorOffset
		),
		ve.ce.getOffset(
			this.nativeSelection.focusNode,
			this.nativeSelection.focusOffset
		)
	);
	if ( modelRange.equals( impliedModelRange ) ) {
		// Current native selection fits model range; don't change
		return false;
	}
}

Specifically the calls to ve.ce.getOffset.

Here we are constructing a fake range from the native selection to see if it is correct. The native range in Safari must be outside the VE surface somehow, causing this exception. We could try to find the root of this error, but equally we could just try/catch this, and say any native selection outside the doc is a null range.

In the specific stack trace I looked at it was triggered during ve.ce.LinearDeleteKeyDownHandler. I tested deleted various things back backspace/delete on a mac but couldn't reproduce the error. If anyone can reproduce this that would be helpful, but I would suggest a try/catch is probably the way to go here. It seems like we are probably just dealing with Safari making a poor choice about where the put the cursor after a delete.

Change 785906 had a related patch set uploaded (by Esanders; author: Esanders):

[VisualEditor/VisualEditor@master] ve.ce.Surface#showModelSelection: Handle out-of-bounds nativeSelection

https://gerrit.wikimedia.org/r/785906

Change 785906 merged by jenkins-bot:

[VisualEditor/VisualEditor@master] ve.ce.Surface#showModelSelection: Handle out-of-bounds nativeSelection

https://gerrit.wikimedia.org/r/785906

Change 790412 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (5c075c883)

https://gerrit.wikimedia.org/r/790412

Change 790412 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (5c075c883)

https://gerrit.wikimedia.org/r/790412

(We should check the error logs instead)

This is the closest to steps to reproduce and I can't seem to reproduce as well. Kindly advise on a better approach to test.

In T306218#7877989, @Esanders wrote:

In the specific stack trace I looked at it was triggered during ve.ce.LinearDeleteKeyDownHandler. I tested deleted various things back backspace/delete on a mac but couldn't reproduce the error. If anyone can reproduce this that would be helpful, but I would suggest a try/catch is probably the way to go here. It seems like we are probably just dealing with Safari making a poor choice about where the put the cursor after a delete.

I think no one has any idea how to reproduce it, so my suggested approach is to instead wait for the change to be deployed, and then check the Logstash dashboards linked earlier in the discussion and verify that this error stopped occurring.

Looks fixed: