1286769 - Focus on an empty contenteditable resulting no ClientRect in the selection range

Status: NEW

(Core :: DOM: CSS Object Model, defect, P3)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: range-getBoundingClientRect.html

STR: Run test case and look at the first test, it creates an empty contenteditable, focus it, and access the selection range through `window.getSelection().getRangeAt(0)`.

Expected:

There should be one ClientRect returned in Range#getClientRects() so I would know the position and height of the caret. Like what Chrome do:

range.getClientRects().length: 1
Rect: {
  "width": 457,
  "height": 18,
  "top": 8,
  "bottom": 26,
  "left": 8,
  "right": 465
}

Actual:

There isn't any ClientRect returned.

range.getClientRects().length: 0

Note:

I would doubt this is in any spec. What Chrome does isn't technically correct either since it's rect has the full width of the input area.

I also don't know if I filed this bug in the correct component...

Comment 1

[Andrew Overholt [:overholt]]

Boris, what do you think?

Comment 2

[Boris Zbarsky [:bzbarsky]]

No opinion; I've more or less avoided thinking about selection and how it interacts with carets....

That said, I vaguely recall there being problems with modeling the caret as a selection.  Masayuki might know more, or who would know more...

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/8)]

Hmm, I don't know what it returns in this case:
https://drafts.csswg.org/cssom-view/#dom-element-getclientrects
https://developer.mozilla.org/en-US/docs/Web/API/Element/getClientRects

And empty contenteditable element without any style is differently rendered in each browser. See bug 1098151. If |div[contenteditable] { height: 0; }| is specified, what happens on the other browsers?

Comment 4

[Andrew Overholt [:overholt]]

ni? for comment 3

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: range-getClientRects-height-0.html

Selection results no range (rangeCount=0) on all tests in Chrome, after setting the height to 0.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

... and Firefox continue to output the same information.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/8)]

Then, fixing 1098151 will fix this bug too, no?

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

No, adding |div[contenteditable] { min-height: 1em; }| I still don't see any ClientRect returned from the range. The bug here is about inability for ClientRect to be consistent and allow web content to, for example, put a `<div>` right under the caret, like what GitHub do when you type @ in a comment*.

Bug 1097649 (and it's dup bug 1097649) is more about the min-height of a contenteditable div.

(* I don't really know how GitHub do it, their comment box is a <textarea> where we do not return ClientRect for the selection within it anyway. StackOverflow suggests creating a hidden <div> to reproduce the text flow and read back the text coordinates, which I doubt it is the case...)

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

> (* I don't really know how GitHub do it, their comment box is a <textarea>
> where we do not return ClientRect for the selection within it anyway.
> StackOverflow suggests creating a hidden <div> to reproduce the text flow
> and read back the text coordinates, which I doubt it is the case...)

... and their minified JS contained a AMD module named "github/text-field-mirror".

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/8)]

Thank you for your confirmation. I checked the testcases with IE/Edge. Then, IE/Edge returns caret rect (but its with is 0). It makes sense to me better than Chrome's behavior...

Anyway, currently, we don't create rect when there is no text node nor nsTextFrame. In such case, we should *guess* the caret rect with font metrics of the container.
https://dxr.mozilla.org/mozilla-central/rev/4c05938a64a7fde3ac2d7f4493aee1c5f2ad8a0a/dom/base/nsRange.cpp#2928,2956-2961