Something is blocking contenteditable from unselecting text

[jamesthomsondev]

What is the problem?

An event (or something else) is blocking selected text in a contenteditable from being unselected.

What is the current behavior?

When you select text in contenteditable and try to unselect it by clicking anywhere else in the document, it won't unselect the text.

Please provide the steps to reproduce and create a JSFiddle.

1. Select text within contenteditable
2. Click anywhere else in the document body that isn't another contenteditable

Note: If you don't initialise selection-js, this works perfectly fine.

https://jsfiddle.net/jamesbrndwgn/uevos4yg/13/

What is the expected behavior?

When clicking away from a contenteditable (i.e. blur), the text should unselect as per the regular browser behaviour.

Your environment:

Version (SelectionArea.version): 2.0.1
Browser:  Chrome 89.0.4389.82
OS:  Mac OS X 10.15.7

[jamesthomsondev]

Did a bit of digging this morning and found that the offending line is this one: https://github.com/Simonwep/selection/blob/0a9fd4084f8e4e1dc1068aa05aed6651dbdafd95/src/index.ts#L166

What's the purpose of blocking the selectstart event? Does it interfere with the library?

I cloned your package and removed this line and based on some of my basic tests it doesn't seem to impact anything. I of course am not as familiar with the code so could be overlooking something. If it is required for certain use cases, then perhaps this could be better set as a config option.

[simonwep]

Does it interfere with the library?

Heavily, yes - if you do not prevent the start of a regular selection it'll signal the browser that you're selecting text. This causes the browser to handle things such as scrolling which in the end will the selection you wanted to fail.

If it is required for certain use cases, then perhaps this could be better set as a config option.

I don't want to do that, the problem isn't obvious and it'd lead to unexpected results.

I'll take a look at this and see what I can do :)

[simonwep]

I am wrong - or rather, it this was the case before v2. It is no longer a problem since the layouting got refactored. Fixed in 606b36f.

Background: In v1 the whole "where is the reactangle - what elements are being touched" thingy wasn't really fully work out. In firefox if you had moved your mouse to the bottom of the page the whole thing broke since it couldn't handle both the page-wide scrolling and the local, container-based scrolling. This has been fixed around v2 (not sure anymore) and is no longer required :)