Where did you install Firefox from? Help Mozilla uncover 3rd party websites that offer problematic Firefox installation by taking part in our campaign. There will be swag, and you'll be featured in our blog if you manage to report at least 10 valid reports!

Sykje yn Support

Mij stipescams. Wy sille jo nea freegje in telefoannûmer te beljen, der in sms nei ta te stjoeren of persoanlike gegevens te dielen. Meld fertochte aktiviteit mei de opsje ‘Misbrûk melde’.

Learn More

Development: Very specific problem with getting the caret position in a contenteditable div

  • 3 antwurd
  • 0 hawwe dit probleem
  • 1 werjefte
  • Lêste antwurd fan cor-el

more options

Hello, I'm a web developer. I'm using the Firefox Developer Edition and currently working on a project that requires caret manipulation. I have this function right here that fetches the caret's client rect: ``` function getCaretRect(): DOMRect | null {

 const sel = window.getSelection()
 if (!sel || sel.rangeCount === 0) return null
 const range = sel.getRangeAt(0)
 const rects = range.getClientRects()
 if (rects.length === 0) return null
 return rects[0]

} ``` Here is where the issue arises. Suppose I have a contenteditable div with two line breaks (no new lines), and the second line is smaller than the first one. If the caret is positioned somewhere that is further than the end of the second line, and I press the down arrow key, then left, for some reason the caret rect I get has all values set to zero, like this: `{ x: 0, y: 0, width: 0, height: 0, top: 0, right: 0, bottom: 0, left: 0 }` I will add an image to explain further.

I don't have this issue on Chromium based browsers, but cross browser support is important for me.

There is one more issue to do with caret manipulation which is how contenteditable divs are handled. On a Chromium based browser, if I have a parent div that's contenteditable, then another div that's not contenteditable (contenteditable="false" explicitly), then two children divs which are both contenteditable (or more), I can navigate through the divs freely using the arrow keys and focus is managed better alongside event handlers. This is not present on Firefox, however.

If this is not the right place to ask for help then please guide me where is more suitable.

Hello, I'm a web developer. I'm using the Firefox Developer Edition and currently working on a project that requires caret manipulation. I have this function right here that fetches the caret's client rect: ``` function getCaretRect(): DOMRect | null { const sel = window.getSelection() if (!sel || sel.rangeCount === 0) return null const range = sel.getRangeAt(0) const rects = range.getClientRects() if (rects.length === 0) return null return rects[0] } ``` Here is where the issue arises. Suppose I have a contenteditable div with two line breaks (no new lines), and the second line is smaller than the first one. If the caret is positioned somewhere that is further than the end of the second line, and I press the down arrow key, then left, for some reason the caret rect I get has all values set to zero, like this: `{ x: 0, y: 0, width: 0, height: 0, top: 0, right: 0, bottom: 0, left: 0 }` I will add an image to explain further. I don't have this issue on Chromium based browsers, but cross browser support is important for me. There is one more issue to do with caret manipulation which is how contenteditable divs are handled. On a Chromium based browser, if I have a parent div that's contenteditable, then another div that's not contenteditable (contenteditable="false" explicitly), then two children divs which are both contenteditable (or more), I can navigate through the divs freely using the arrow keys and focus is managed better alongside event handlers. This is not present on Firefox, however. If this is not the right place to ask for help then please guide me where is more suitable.
Keppele skermôfbyldingen

Alle antwurden (3)

more options

Heads up considering the screenshot. For the last part, it's actually when I bind it to the ArrowLeft key, not the ArrowDown key.

Behelpsum?

more options

I reported this issue in Bugzilla. Sorry for any inconveniences!

Behelpsum?

more options

For reference:

  • 1904255 - Under specific circumstances, I get the wrong DOMRect for the current selection (or caret position) in a contenteditable div

Behelpsum?

In fraach stelle

Jo moatte jo oanmelde by jo account om op berjochten te antwurdzjen. Stel in nije fraach as jo noch gjin account hawwe.