Closed Bug 1426709 Opened 2 years ago Closed 10 months ago

stack-overflow in [@ mozilla::HTMLEditRules::WillDeleteSelection]

Categories

(Core :: DOM: Editor, defect, P3, critical)

59 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla69
Tracking Status
firefox-esr60 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- wontfix
firefox69 --- fixed

People

(Reporter: tsmith, Assigned: masayuki)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression, testcase)

Attachments

(2 files)

Attached file testcase.html
==3432==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc121d0e38 (pc 0x0000004be058 bp 0x7ffc121d1690 sp 0x7ffc121d0e40 T0)
    #0 0x4be057 in __asan_memcpy /builds/worker/workspace/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cc:23:3
    #1 0x7f7ec4b8f313 in RangeBoundaryBase /src/obj-firefox/dist/include/mozilla/RangeBoundary.h:34:7
    #2 0x7f7ec4b8f313 in EditorDOMPointBase /src/obj-firefox/dist/include/mozilla/EditorDOMPoint.h:20
    #3 0x7f7ec4b8f313 in mozilla::EditorBase::GetNextNodeInternal(mozilla::EditorDOMPointBase<nsINode*, nsIContent*> const&, bool, bool) /src/editor/libeditor/EditorBase.cpp:3428
    #4 0x7f7ec4c784cd in GetNextEditableHTMLNodeInternal /src/editor/libeditor/HTMLEditor.cpp
    #5 0x7f7ec4c784cd in GetNextEditableHTMLNodeInBlock /src/obj-firefox/dist/include/mozilla/HTMLEditor.h:826
    #6 0x7f7ec4c784cd in mozilla::HTMLEditRules::GetPromotedPoint(mozilla::HTMLEditRules::RulesEndpoint, nsINode&, int, EditAction) /src/editor/libeditor/HTMLEditRules.cpp:5872
    #7 0x7f7ec4bdcf39 in mozilla::HTMLEditRules::PromoteRange(nsRange&, EditAction) /src/editor/libeditor/HTMLEditRules.cpp:6027:5
    #8 0x7f7ec4c507e4 in mozilla::HTMLEditRules::GetNodesFromPoint(mozilla::EditorDOMPointBase<nsCOMPtr<nsINode>, nsCOMPtr<nsIContent> > const&, EditAction, nsTArray<mozilla::OwningNonNull<nsINode> >&, mozilla::HTMLEditRules::TouchContent) /src/editor/libeditor/HTMLEditRules.cpp:6598:3
    #9 0x7f7ec4c4dbc5 in mozilla::HTMLEditRules::MoveBlock(mozilla::dom::Element&, mozilla::dom::Element&, int, int) /src/editor/libeditor/HTMLEditRules.cpp:3231:17
    #10 0x7f7ec4c44bae in mozilla::HTMLEditRules::TryToJoinBlocks(nsIContent&, nsIContent&) /src/editor/libeditor/HTMLEditRules.cpp:3043:9
    #11 0x7f7ec4bf6f4f in mozilla::HTMLEditRules::WillDeleteSelection(mozilla::dom::Selection*, short, short, bool*, bool*) /src/editor/libeditor/HTMLEditRules.cpp:2491:11
    #12 0x7f7ec4bfce65 in mozilla::HTMLEditRules::WillDeleteSelection(mozilla::dom::Selection*, short, short, bool*, bool*) /src/editor/libeditor/HTMLEditRules.cpp:2507:16
    #13 0x7f7ec4bfce65 in mozilla::HTMLEditRules::WillDeleteSelection(mozilla::dom::Selection*, short, short, bool*, bool*) /src/editor/libeditor/HTMLEditRules.cpp:2507:16
    #14 0x7f7ec4bfce65 in mozilla::HTMLEditRules::WillDeleteSelection(mozilla::dom::Selection*, short, short, bool*, bool*) /src/editor/libeditor/HTMLEditRules.cpp:2507:16
    ...
Flags: in-testsuite?
Priority: -- → P1
Assignee: nobody → m_kato
Moving to p3 because no activity for at least 24 weeks.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P1 → P3

Could be fixed by bug 1547897.

See Also: → 1547897

Hmm, actually, different bug from bug 1547897. Taking.

Assignee: m_kato → masayuki
Severity: normal → critical
Status: NEW → ASSIGNED
OS: Unspecified → All
Hardware: Unspecified → All

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().

See Also: → 1487301

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.

Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/47613941fb5d
Make HTMLEditor update selection ancestor limit synchronously when editing host is changed to ancestor element r=smaug
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.