Open Bug 1417535 Opened 5 years ago Updated 2 months ago

getSelection() returns wrong anchorNode/anchorOffset when selection contains nested different contenteditable context


(Core :: DOM: Selection, defect, P3)

58 Branch





(Reporter: varoot, Unassigned)




(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171103003834

Steps to reproduce:

This happens when contenteditable=true is nested inside contenteditable=false inside another contenteditable=true

1. See this fiddle
2. Make a text selection over contenteditable part (-><-). For example from the word "selection" to "space"

Actual results:

anchorOffset is 0
anchorNode is (text) "<- space and look at values below."

This is not the correct node and offset

Expected results:

(From Chrome and Edge)
anchorOffset is 21
anchorNode is (text) "Try moving your selection over this ->"
Component: Untriaged → DOM
Product: Firefox → Core
Component: DOM → Selection
Priority: -- → P3
See Also: → 1522492


This is happening because the way that range and selection in Chrome and Edge is different. (As a side, soon Edge will use the Chromium engine.)

Both Chrome and Safari change the selection in the selection object and the range in the range object to what they determine is the visible area. This change was made a few years ago when they shared a common webkit codebase.

I would suggest that in the interest of promoting standard behaviour between browsers that we follow their lead. Having written more than a few html editors in my day, I can tell you that it would result in better quality and less code.



Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.