Bug in Microsoft Edge (MOVED TO: ContentSelect)

[megamuf]

Hello,

in Microsoft Edge 38.14393.0.0 - Microsoft EdgeHTML 14.14393 version,

if you select text with last character in a tag(text without the last character in a tag, works great):

bold italic and link, gives an error message:

[cgriffin4]

I've extensively reviewed why this happens in some instances and I believe I know the bug's cause (or most reproducible situation). Oddly, in Edge 20 this bug seems even less common. It only occurs when you have an element at the end of a section and then highlight it (or at least one character from the end of it).

Example Edit showing bug: <li>A line with a <a href="#">link<a></li>

Detailed Explanation: When selecting link in this example, Edge puts the end of the selection outside the textNode and gives an incorrect endOffset (it's 2 in this example, maybe the number of child nodes?). End result is the _fromRange is 14 (correct) but the _toRange is getOffsetOfChildNode(divNode, divNode) which equals 18 (full length of node because it is not a child) and then afterwards the endOffset is added.

Workaround, maybe?: Only adding endOffset to getOffsetOfChildNode if element !== endNode seems to work in my (limited) testing. But this is almost certainly a selection bug that would be more indicative of bigger issues and this "fix" will likely not solve the bigger issue of window.getSelection() behaving oddly at the end of your content areas. I'd love to get @anthonyjb input on what/where a proper solution should be implemented.

Comparatively in Chrome: Highlighting the word link will result in the proper selected range of [14, 18] in Chrome. this is because window.getSelection() returns the text node as the anchorNode. So window.getSelection().getRangeAt(0) has the startContainer and endContainer as the textNode with startOffset = 0 and endOffset = 4. At this point element is equal to the div that was generated by ContentTools and _getOffsetOfChildNode works as intended.

Edit: Same bug present at the beginning of sections.

[anthonyjb]

@cgriffin4 first of thank you for the excellent information here - I don't have native access to IE so it's hugely helpful that you've taken the time to investigate the bug to such a degree.

---

What next...

I'm going to be closing the issue here and moving it to ContentSelect since what you've highlighted shows that this is where the problem lies and will need to be fixed.

Then I need to resolve the issue. I think at least short term we'll need to look to provide a hack of sorts for IE's behaviour, to be fair to IE in my experience all the browsers behave a little different when handling selected content ranges so it was it is.

So steps for resolving will be as follows:

• I'll add a test for the specific issue you've highlighted above (again thank you for that) and that should give me an easy to repeat test case on ContentSelect.
• I'll use BrowserStack to check I can make the test fail in IE (10, 11 and Edge).
• I'll look to move window.selection into a separate function so that we can cleanly manage any hack for IE and also that will allow people to change it's behaviour easily (something people have asked about with regard to IFRAMES.

[anthonyjb]

This issue has been moved here: https://github.com/GetmeUK/ContentSelect/issues/2