Closed Bug 1470968 Opened 6 years ago Closed 4 years ago

Selection doesn't work properly in nested contenteditables

Categories

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

Product:
Core
Component:
DOM: Selection
Version:
60 Branch
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1506547

People

(Reporter: tom, Unassigned)

References

(Blocks 2 open bugs,
URL
)

Details

(Keywords: parity-chrome, parity-edge, testcase, Whiteboard: [DUPEME?][h2review-noted])

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36 Steps to reproduce: Using nested contenteditables (outer is "true", inner is "false"), clicking into the inner one. See https://jsfiddle.net/8poct32b/ for minimal example or here: <div contenteditable="true"> This text can be modified <div contenteditable="false"> whereas this not. Selection also doesn't work here. </div> </div> Actual results: The whole content of the inner div was selected. Expected results: It should be able to select just parts of the div content.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 20180625220119 Confirming because the issue is reproducible and behavior differs from other browsers. I didn't notice any obvious duplicates, but there are numerous related reports that might not have an obvious summary or STR but could be the same underlying issue, like bug 1074737 for example.
URL: https://jsfiddle.net/8poct32b/
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → Selection
Ever confirmed: true
Keywords: parity-chrome, parity-edge, testcase
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Whiteboard: [DUPEME?]
Priority: -- → P3

Similar problems also occur with nesting user-select.

One of the other big differences between Firefox and the other browsers is that the other browsers set the range and selection objects to the visible area rather than the bounding element. In this example, I have noticed that the browser thinks that the selection is the element with contenteditable applied. Do you think this could have anything to do with the behaviour?

Cheers,

Alex

Makoto, does this still reproduce for you? It's working for me on Windows and macOS. Thanks.

Flags: needinfo?(m_kato)
Whiteboard: [DUPEME?] → [DUPEME?][h2review-noted]

I think that this has fixed by bug 1506547.

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(m_kato)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.