Selections not returned in correct DOM order

[chitgoks]

in edge no rects are returned

in ie not all rects are returned

in firefox rects returned are not sorted

[edg2s]

I've just tested all these browsers with the demo (http://edg2s.github.io/rangefix/) and they all appear to work fine. Can you give more detailed reproduction steps?

[chitgoks]

my bad. it looks like the bug from edge/ie has been ongoing, when div position is absolute, getClientRects() returns empty in the latest versions of the browsers. there was a workaround before but now it does not work.

[chitgoks]

@edg2s but i can confirm that latest in firefox does not output the rectangles in order using rangefix.
if i just use window.getSelection().getRangeAt(0), it gives the correct order of rectangles.

[chitgoks]

@edg2s i think this is considered a bug in firefox since it does not produce clientrects in correct order. as mentioned in previous comment, if window.getSelection().getRangeAt(0).getClientRects() is used, then it gives out correct sequence of clientrects.

[alecgibson]

I've also got the Firefox sorting issue. We're working around it right now by manually sorting the rectangles we get back.

Repro steps:

1. Open Firefox 67.0.4 on macOS
2. Go to this pen
3. Open your console
4. Select some text across multiple lines/paragraphs
5. Look at the rectangles displayed in the console
6. I'd expect these rectangles to be sorted top-to-bottom, and left-to-right, but they're not

[chitgoks]

yes that is what i did right now. in edge future version it is going to be fixed.

[edg2s]

We're working around it right now by manually sorting the rectangles we get back.

According to the spec they should be returned in "content order": https://drafts.csswg.org/cssom-view/#dom-range-getclientrects which I assume means DOM order (and this is how vendors are appearing to implement it), not Cartesian.

This should be fairly easy to fix.

[alecgibson]

Sure, DOM order is correct, but it's not coming back in the order currently either.

[edg2s]

Indeed, hence "This should be fairly easy to fix." and the subsequent patch :)

[alecgibson]

@edg2s thanks for the patch - it seems to mostly work. However, I think if the DOM tree is deep, then the rectangles are still being processed in the wrong order. Take this pen for example.

In Chrome, if I highlight from the non-formatted text at the start, to the text that is both bold and italic (ie the DOM tree is 2 levels deep), then the highlights appear in the (correct) order of red-purple-blue (first child is red, and last child is blue):

However, if I do this in Firefox, it's in the wrong order of red-blue-purple (ie the "last child" is in the middle of the selection):

Note that in Firefox, if my selection starts and ends at the same depth in the DOM, it appears fine - it's only if the start and end are at different depths.