Crash in [@ mozilla::DeleteNodeTransaction::DeleteNodeTransaction]
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox-esr91 | --- | unaffected |
firefox91 | --- | unaffected |
firefox92 | --- | unaffected |
firefox93 | --- | wontfix |
firefox94 | --- | fixed |
People
(Reporter: mccr8, Assigned: masayuki)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
Crash report: https://crash-stats.mozilla.org/report/index/da7e2adc-ac8a-4c45-9532-9fbc40210826
MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(HTMLEditUtils::IsRemovableNode(aContentToDelete))
Top 10 frames of crashing thread:
0 XUL mozilla::DeleteNodeTransaction::DeleteNodeTransaction editor/libeditor/DeleteNodeTransaction.cpp:36
1 XUL mozilla::DeleteNodeTransaction::MaybeCreate editor/libeditor/DeleteNodeTransaction.cpp:24
2 XUL mozilla::EditorBase::DeleteNodeWithTransaction editor/libeditor/EditorBase.cpp:2212
3 XUL mozilla::EditorBase::InsertTextIntoTextNodeWithTransaction editor/libeditor/EditorBase.cpp:3077
4 XUL mozilla::EditorBase::InsertTextWithTransaction editor/libeditor/EditorBase.cpp:2914
5 XUL mozilla::HTMLEditor::HandleInsertText editor/libeditor/HTMLEditSubActionHandler.cpp:1072
6 XUL mozilla::EditorBase::InsertTextAsSubAction editor/libeditor/EditorBase.cpp:6007
7 XUL mozilla::EditorBase::OnCompositionChange editor/libeditor/EditorBase.cpp:3673
8 XUL mozilla::EditorEventListener::HandleChangeComposition editor/libeditor/EditorEventListener.cpp:1068
9 XUL mozilla::EventListenerManager::HandleEventInternal dom/events/EventListenerManager.cpp:1312
5 crashes from a single installation. It looks like this diagnostic assert was added in bug 1727185.
Comment 1•3 years ago
|
||
Set release status flags based on info from the regressing bug 1727185
Comment 2•3 years ago
|
||
Masayuki, does this newly added assert crash ring any bell?
Assignee | ||
Comment 3•3 years ago
|
||
Yeah, this detects a bug of HTMLEditor
here:
https://searchfox.org/mozilla-central/rev/5f81c5091d442d829120e19477ba869ae5219709/editor/libeditor/EditorBase.cpp#3071-3075
The stack means that composition string of IME becomes empty, and the text node is being deleted because of unnecessary, however, the node is already not editable. I'm not sure what's going on in the web apps because it's really tricky case that disabling editable state of composing element...
Can I know the URL of crashed web apps (via email or something)?
Reporter | ||
Comment 4•3 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #3)
Can I know the URL of crashed web apps (via email or something)?
There's one URL that shows up twice in crash reports: https://webk.telegram.org/
Assignee | ||
Comment 5•3 years ago
|
||
Thank you. That's helpful even though I cannot reproduce this bug.
Perhaps, this depends on IME. If IME does not consume Escape
key or something which is handled by web apps to move focus or something, then, contenteditable
may be set to false
before we delete the text node from editor.
Assignee | ||
Comment 6•3 years ago
|
||
It seems that this requires a run of a legacy mutation event listener, but there are no one at least in the chat at least...
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
Although we don't have a testcase, HTMLEditor
may need to delete a text node
if it's created for composition. If it's not allowed, users may see staying
composition string in disabled editor.
Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/de32238c780f Make `DeleteNodeTransaction` allow to create its instance for non-editable text node which was created or modified by an editor r=m_kato
Comment 9•3 years ago
|
||
bugherder |
Comment 10•3 years ago
|
||
The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Comment 11•3 years ago
|
||
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #10)
The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?
If not please setstatus_beta
towontfix
.For more information, please visit auto_nag documentation.
Hi Makoto-san,
Masayuki is away for a week. I don't think this is important enough to uplift to beta, as the patch mainly relaxed assertion criteria for non-release builds. Does that sound right?
Comment 12•3 years ago
|
||
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #11)
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #10)
The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?
If not please setstatus_beta
towontfix
.For more information, please visit auto_nag documentation.
Hi Makoto-san,
Masayuki is away for a week. I don't think this is important enough to uplift to beta, as the patch mainly relaxed assertion criteria for non-release builds. Does that sound right?
Yes, this issue is MOZ_DIAGNOSTIC_ASSERT_IF
, and this assertion is enabled on nightly and dev edition only.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•