stack-overflow in [@ mozilla::HTMLEditRules::WillDeleteSelection]
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
People
(Reporter: tsmith, Assigned: masayuki)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression, testcase)
Attachments
(2 files)
Updated•8 years ago
|
Updated•8 years ago
|
| Reporter | ||
Updated•8 years ago
|
Updated•8 years ago
|
Updated•8 years ago
|
Comment 1•7 years ago
|
||
| Assignee | ||
Comment 3•7 years ago
|
||
Hmm, actually, different bug from bug 1547897. Taking.
| Assignee | ||
Comment 4•7 years ago
|
||
This is a similar issue of what was fixed by bug 1487301. When an ancestor of current active editing host becomes contenteditable, HTMLEditor may not receive focus event yet and the selection ancestor limiter may not be reset when handling an edit action caused by HTMLDocument.execCommand().
| Assignee | ||
Comment 5•7 years ago
|
||
HTMLEditor initializes selection ancestor limit when it receives focus
event. If HTMLDocument.execCommand() is called immediately after an
ancestor of active editing host becomes new editing host,
HTMLEditor::GetActiveEditingHost() returns the new one, but selection
ancestor limit is still the previous one. This mismatch causes a lot of
bugs. Therefore, this patch makes nsGenericHTMLElement notifies HTMLEditor
of an element becoming contenteditable, and makes HTMLEditor update
selection ancestor limit only when the new editing host is ancestor of
old selection ancestor limit.
Updated•7 years ago
|
Comment 7•7 years ago
|
||
| bugherder | ||
| Assignee | ||
Updated•7 years ago
|
Updated•7 years ago
|
Description
•