Range.getClientRects reports incorrect rects for inline-wrapped inline-block item, when triple clicking to select paragraph
Categories
(Core :: DOM: CSS Object Model, defect)
Tracking
()
People
(Reporter: ejsanders, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.193 Safari/537.36
Steps to reproduce:
(1) Visit https://edg2s.github.io/rangefix/
(2) Click the "Firefox triple click bug" button or triple click the paragraph which contains the inline image.
Actual results:
The rectangle for the <u> tag does not include the full height of the image tag.
Expected results:
The computed rectangles are correct.
See https://github.com/edg2s/rangefix/issues/14 for screenshots and more dicsussion.
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
getClientRects() doesn't include rects from overflowing stuff, and the image overflows the <u> element. Consider:
data:text/html,<!doctype html><div style="width: 100px; height: 100px;"><div style="width: 100px; height: 200px"></div></div>
document.querySelector("div").getClientRects() doesn't include the 200px rect, in any browser. Why should the inline case be different? Even the chrome devtools agree that the <u> is not as tall as the <img>.
But Chrome seems to do the same as us... so for what element exactly is getClientRects() returning the wrong result?
If the issue is just overflowing content, then the rectangles should be the same if I make the selection by dragging, but it isn’t.
|
|
||
Comment 3•5 years ago
|
||
Ah, this is about Range.getClientRects, not about Element.getClientRects, sorry...
So spec is in https://drafts.csswg.org/cssom-view-1/#dom-range-getclientrects:
For each element selected by the range, whose parent is not selected by the range, include the border areas returned by invoking getClientRects() on the element.
So it seems to me that if <u> is selected by the range completely, then we'd return an smaller rect than if it wasn't per the above definition (because when <u> is not fully selected, then we union the getClientRects() of the text and the image, instead of just returning the rects of the <u>). That seems unfortunate, though it's what the spec seems to call for.
|
|
||
Comment 4•5 years ago
|
||
I think you should file an issue in https://github.com/w3c/csswg-drafts/issues/new, as this seems an issue with the way Range.getClientRects is defined.
|
||
Comment 5•5 years ago
|
||
The severity field is not set for this bug.
:mats, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Comment 6•5 years ago
|
||
This seems invalid per spec, see above in comment 3.
Description
•