How to reproduce:

1. Open http://edg2s.github.io/rangefix/ in Firefox 82.0.2
2. Triple click to select the whole line with the example image
3. 

When we select text 'Vestibulum neque massa, scelerisque sit amet ligula eu, congue molestie mi. Praesent ut
varius sem. Nullam at porttitor arcu, nec lacinia nisi. Ut ac dolor vitae odio interdum
condimentum.' from given sample pdf file then
let range = document.getSelection().getRangeAt(0);
RangeFix.getClientRects(range); returns the 3 rects in firefox and 4 rects in chrome browser.
Please find the attached document.
file-sample_150kB.pdf

Hi,

I am experiencing a werid range.getBoundingClientRect() bug on https://www.theguardian.com/international. For my layout analyzer layoutstats, I want to calculate the area and the positions of all visible text nodes on the page.

I am using range.getBoundingClientRect() for that purpose. If the analyzed textnode spans multiple lines, the reported left and right values of the ClientRect are way off the correct numbers (see code and screenshot), range.getClientRects() reports that there is just one client rect, however by spec there should be multiple rects (one for each line break)

s = document.querySelector('#spotlight > div >... (selector copied from chrome developer tools)...')
s.childNodes[0].textContent; //"America’s eviction epidemic"
r = document.createRange(); 
r.selectNode(s.childNodes[0]);
console.log(r.getBoundingClientRect());  
//ClientRect {top: 142.09375, right: 1295.75, bottom: 162.09375, left: 1081.5, width: 214.25…}
//expected {left: 438. right: 898, (other values ok)} - see screenshot
r.getClientRects() //1, should be 2 client rects according to spec

Can rangefix correct this behaviour? If not, is this an intentional behaviour or a browser bug?

I say redundant because the dimension of a few client rects are almost the same, with the only difference sometimes is lesser height by a few pixels or perhaps width.

Would be a nice feature if this gets cleaned up and only the rect with the larger area gets returned.

if the selection is more than 1 line, only 1 line is returned.

1. Place the cursor after the last word on a line
2. Select the space to the right, up to the next character, or one character beyond
3. Observe incorrect bounding boxes in various browsers:

Selection "from[ ]here" in Chrome (broken):

Selection "from[ h]ere" in Chrome (not broken):

Selection "from[ ]here" in Firefox (not broken):

Selection "from[ h]ere" in Firefox (broken):

The fixed version of getClientRects() returns two copies of client rects for RTL text. Here's a fork of your demo which shows the problem. If you select the first line line which includes the Arabic text, then view the highlights in the web inspector, you'll see that the client rect corresponding to the RTL span appears twice:

https://rawgit.com/jahewson/rangefix/master/demo.html

P.S. Good work with this fix, because Chrome doesn't seem to be progressing on this front.

All versions of IE/Edge don't handle bi-di text correctly. It's possible there is no performant way to fix this, but worth investigating.

in edge no rects are returned

in ie not all rects are returned

in firefox rects returned are not sorted