fix: selectionchange should triggered by the user event rather than api event

[electroluxcode]

The PR is to completely solve issue1 in #5771 by controlling the triggering behavior of users.

inherited from #5772 . Due to uncertainty about the side effects brought by this PR, it is temporarily submitted as a draft PR. In this #5772, in order to solve issue1 inside, I added a variable named onDOMSelectionChangeThrottleTime.

Then, I found that when this variable is set to the extremely small value of 0, there is still a 20-30% probability that the selection area is invalid when the QPS is 50, and a second click is required to select the selection area.

In the past, when a collaborator selected a certain block for editing, the scheduleOnDOMSelectionChange of the other collaborators were actually being rendered all the time. However, the selection area of one collaborator should not be able to affect the selection area of another collaborator. It appears to be a design issue regarding the event stream.

Therefore, referring to the event triggering of quill, https://github.com/slab/quill/blob/20f02f55e30ca87c0c539632b36c6c52ca4670eb/packages/quill/src/core/selection.ts#L54-L68

The onClick event was changed to onMouseUp and onMouseDown (the main reason is that the timing of the onClick event is too late. When the onClick event is triggered, the selection area has already changed). And these two events generate a variable mouseDown, which is used to control the triggering of selectionchange. This ensures that only user actions can trigger selectionchange, and API actions cannot actively trigger it.

The setTimeout in

slate/packages/slate-react/src/components/editable.tsx

Lines 459 to 462 in 5a1c728

	setTimeout(() => {
	state.isUpdatingSelection = false
	})
	return

seems to cause abnormal behavior of the selection area. Changing it to synchronously call state.isUpdatingSelection as in the PR will not cause abnormalities. What is this design for?

[changeset-bot]

⚠️ No Changeset found

Latest commit: 658ce3b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[dylans]

@electroluxcode Overall it seems reasonable and consistent with what I know about event timing, but it does appear to possibly be trigger a series of test failures (it's entirely possible the test suite is wrong and needs to be adjusted), or could be a flaky test.