2083772 - Crash in [@ mozilla::detail::InvalidArrayIndex_CRASH | mozilla::HTMLEditor::AutoDeleteRangesHandler::FallbackToDeleteRangesWithTransaction]

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Clouseau (:calixte)]

Crash report: https://crash-stats.mozilla.org/report/index/ab2baff9-16e2-4b9b-9181-957160261019

MOZ_CRASH Reason:

ElementAt(aIndex = 0, aLength = 0)

Top 10 frames:

0  firefox-bin  mozilla::detail::InvalidArrayIndex_CRASH(unsigned long, unsigned long)  mfbt/Assertions.cpp:50
1  libxul.so  mozilla::HTMLEditor::AutoDeleteRangesHandler::FallbackToDeleteRangesWithTransact...  editor/libeditor/HTMLEditorDeleteHandler.cpp
2  libxul.so  mozilla::HTMLEditor::AutoDeleteRangesHandler::Run(mozilla::HTMLEditor&, short, s...  editor/libeditor/HTMLEditorDeleteHandler.cpp:1261
3  libxul.so  mozilla::HTMLEditor::HandleDeleteSelection(short, short)  editor/libeditor/HTMLEditorDeleteHandler.cpp:700
4  libxul.so  mozilla::EditorBase::DeleteSelectionAsSubAction(short, short)  editor/libeditor/EditorBase.cpp:5306
5  libxul.so  mozilla::EditorBase::DeleteSelectionAsAction(short, short, nsIPrincipal*)  editor/libeditor/EditorBase.cpp:5269
6  libxul.so  mozilla::EditorCommand::DoCommand(nsTSubstring<char> const&, nsICommandParams*, ...  editor/libeditor/EditorCommands.cpp:62
7  libxul.so  nsBaseCommandController::DoCommand(char const*)  dom/commandhandler/nsBaseCommandController.cpp:54
8  libxul.so  mozilla::DoCommandCallback(mozilla::Command, void*) [clone .188790]  editor/libeditor/EditorEventListener.cpp:94
9  libxul.so  mozilla::WidgetKeyboardEvent::ExecuteEditCommands(mozilla::NativeKeyBindingsType...  widget/WidgetEventImpl.cpp:1369

There is 1 crash in nightly 160 with buildid 20261017095211.

In the last 30 days, Firefox has 1 crash on nightly and 1 crash on release with this signature.

This signature has been reported since build 20250628020740 (2025-06-28), 476 days before the build above.

This bug looks actionable because:

• AutoDeleteRangesHandler::FallbackToDeleteRangesWithTransaction reads aRangesToDelete.FirstRangeRef() on an empty range array when every range to delete is collapsed by the time RemoveCollapsedRanges() runs.

  1. AutoDeleteRangesHandler::Run calls the fallback when ExtendAnchorFocusRangeFor returns eNone. CanFallbackToDeleteRangesWithTransaction allows this even for a collapsed range as long as the original direction is not ignored.
  2. The normalization loop skips collapsed ranges, and WhiteSpaceVisibilityKeeper::NormalizeSurroundingWhiteSpacesToJoin may leave a range collapsed.
  3. aRangesToDelete.RemoveCollapsedRanges() (line 206) then removes every collapsed range and, when none are left, calls RemoveAllRanges(), so mRanges is empty.
  4. IsCollapsed() returns true for an empty mRanges, so the early-return branch runs.
  5. That branch calls aRangesToDelete.FirstRangeRef()->StartRef() (line 209), and FirstRangeRef() is an unchecked mRanges[0], which aborts with an invalid array index.

  The crash reason ElementAt(aIndex = 0, aLength = 0) and the Run -> FallbackToDeleteRangesWithTransaction frames match this. The other FirstRangeRef() at line 174 is protected by the non-empty check in CanFallbackToDeleteRangesWithTransaction. Frame 1 has no line number, so line 209 is inferred from the source, and it is not known which of the two ways the range became collapsed applied here. Look first at the IsCollapsed() early return after RemoveCollapsedRanges(): an empty array needs its own handling, for example returning an empty CaretPoint or using a caret point saved before the loop.

• The failing code comes from 9705a5a223c9 (gh) (bug 1976372) by :masayuki.

Code references:

• mozilla::HTMLEditor::AutoDeleteRangesHandler::FallbackToDeleteRangesWithTransaction
• mozilla::AutoClonedRangeArray::RemoveCollapsedRanges
• mozilla::AutoClonedRangeArray::IsCollapsed
• mozilla::AutoClonedRangeArray::FirstRangeRef
• mozilla::HTMLEditor::AutoDeleteRangesHandler::Run

:masayuki, can you have a look please?

Filed automatically by Clouseau, which analyses nightly crashes with an LLM. Nothing above was written or checked by a human. Please close it as INVALID if it is wrong — that is useful feedback, not a nuisance.

This is not an independent Mozilla discovery: the crash is known here only because somebody submitted the crash report linked at the top. If this duplicates an existing report, please resolve THIS bug as the duplicate and leave the credit with the earlier reporter.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This bug was made at implementing the new path for the blink-compat white-space normalizer. So, the path started running with shipping the new normalizer.

Comment 2

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1658699

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 2083772 - Make `AutoClonedRangeArray::RemoveCollapsedRanges` optionally preserve the primary range even when all ranges are collapsed r=m_kato!

We don't know how to reproduce the crash of bug 2083772. So, returning
error in the case may break some web apps. Therefore, let's try to
keep handling with the anchor-focus range even if all ranges are
collapsed with normalizing the white-spaces.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4bfe808cf25a
https://hg.mozilla.org/integration/autoland/rev/1ac4f8fec143
Make `AutoClonedRangeArray::RemoveCollapsedRanges` optionally preserve the primary range even when all ranges are collapsed r=m_kato

Comment 5

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/1ac4f8fec143

Comment 6

[BugBot [:suhaib / :marco]]

The patch landed in nightly and ESR is affected.

:masayuki, please make an uplift decision for ESR:

• For ESR, nominate the patch for the appropriate ESR uplift approval if the fix should be included in ESR, or set the ESR status flag(s) to wontfix if an uplift isn't needed. Each affected ESR release needs a decision.

Uplift requests can be submitted from Lando: D336962.

See Requesting an Uplift for documentation on how to request an uplift.

For more information, please visit BugBot documentation.

Comment 7

[Phabricator Automation]

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: This is a crash bug.
• Code covered by automated testing?: no
• Fix verified in Nightly?: no
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: We're not sure how to reproduce this bug, but the crash reason is obvious. This patch makes the array never becomes empty in the case so that referring the first element of the array becomes always safe.
• String changes made/needed?: no
• Is Android affected?: yes

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 2083772 - Make `AutoClonedRangeArray::RemoveCollapsedRanges` optionally preserve the primary range even when all ranges are collapsed

We don't know how to reproduce the crash of bug 2083772. So, returning
error in the case may break some web apps. Therefore, let's try to
keep handling with the anchor-focus range even if all ranges are
collapsed with normalizing the white-spaces.

Original Revision: https://phabricator.services.mozilla.com/D336962

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, according to the URL of crash reports, the crashes occurred on some Google and Microsoft apps. E.g., Gmail and Outlook. Might be a notable fix. However, the crash volume is really low.