Steps to reproduce:

1. Open a document with a <textarea> or <input>. Sample: data:text/html,<div contenteditable>text node</div><textarea>textarea</textarea><input value="text box">. (The contenteditable is not affected, and is just there for comparison.)
2. Open the find bar (Ctrl+F).
3. Ensure “Highlight All” is enabled.
4. Search for something that matches inside the textarea/input (e.g. “text” in my sample).
5. Select the textarea/input.
6. Begin composition, e.g. by pressing Ctrl+Shift+U (which normally inserts an underlined “u” while waiting for you to enter the code point number). (I first found it with a Compose key, which normally inserts an underlined “·” while waiting for the compose sequence.)
7. Observe the page crash.

Consistently reproducible. Uncertain if it’s a regression or not: I’m not in the habit of using find in textareas, though I do use my Compose key extremely regularly.

Crash report: https://crash-stats.mozilla.org/report/index/449c53d6-82ca-495f-9919-2c3e70220817

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0 libxul.so mozilla::EditorBase::InsertTextIntoTextNodeWithTransaction editor/libeditor/EditorBase.cpp:3067
1 libxul.so mozilla::EditorBase::InsertTextWithTransaction editor/libeditor/EditorBase.cpp:2892
2 libxul.so mozilla::TextEditor::HandleInsertText editor/libeditor/TextEditSubActionHandler.cpp:473
3 libxul.so mozilla::EditorBase::InsertTextAsSubAction editor/libeditor/EditorBase.cpp:6089
4 libxul.so mozilla::EditorBase::OnCompositionChange editor/libeditor/EditorBase.cpp:3674
5 libxul.so mozilla::EditorEventListener::HandleChangeComposition editor/libeditor/EditorEventListener.cpp:1071
6 libxul.so mozilla::EventTargetChainItem::HandleEvent dom/events/EventDispatcher.cpp:348
7 libxul.so mozilla::EventTargetChainItem::HandleEventTargetChain dom/events/EventDispatcher.cpp:550
8 libxul.so mozilla::EventTargetChainItem::HandleEventTargetChain dom/events/EventDispatcher.cpp:630
9 libxul.so mozilla::EventDispatcher::Dispatch dom/events/EventDispatcher.cpp:1119

I don't see this in 103 but I can repro in nightly, Masayuki can you take a look?

The bug has a crash signature, thus the bug will be considered confirmed.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9f8e174553dcd4a70f2b66fa6e57bd29d551c6cf&tochange=18bbc1d50e89cc4159360c187248218f3f0c4daa

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

The crash is caused by pointToInsert::mParent is nullptr. However, I have no idea why we've not gotten crashed before this change.

Or, we could have reproduced this in debug build, but it's now appeared by using MOZ_DIAGNOSTIC_ASSERT in the method.

I got it. The true regression point is bug 1758420. It stops updating TextComposition::mContainerTextNode at creating CompositionTransaction. Therefore, at first time of a composition, here always unset pointToInsert, so we should update pointToInsert after DoTransactionInternal.

Before the fix of bug 1758420, TextComposition's text node and offset in it
are updated at creating CompositionTransaction. However, it's now put off
until getting the mutations. Therefore, it always unsets pointToInsert at
first time of the composition and fails to notify the listeners.

This patch makes it retrieve the result after calling DoTransactionInternal
and handle the post processing with the new point.

https://hg.mozilla.org/mozilla-central/rev/088af3fb7a18
https://hg.mozilla.org/mozilla-central/rev/4127e56191c9

Comment on attachment 9290601 [details]
Bug 1785311 - Make EditorBase::InsertTextIntoTextNodeWithTransaction update insertion point after executing the transaction r=m_kato!

Beta/Release Uplift Approval Request

• User impact if declined: Beta and DevEdition users will see the tab crash caused by the new diagnostic assertion.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch fixes the true bug caused by bug 1758420 that is inserting new composition text fails to notify the text node data change to the highlighter of findbar, spellchecker, etc, so this does not change any actual behavior of editor. (On Android, this may cause spellchecker not running at first character insertion via IME.)
• String changes made/needed: none
• Is Android affected?: Unknown

(In reply to Pulsebot from comment #10)

Pushed by mlaza@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4127e56191c9
lint fix r=fix CLOSED TREE

For posterity, this appears to belong to bug 1786419.

Comment on attachment 9290601 [details]
Bug 1785311 - Make EditorBase::InsertTextIntoTextNodeWithTransaction update insertion point after executing the transaction r=m_kato!

Approved for 105.0b3.

https://hg.mozilla.org/releases/mozilla-beta/rev/38728523a798

I have reproduced this bug in Beta v 105.0.b2 and verified the fix in Beta v105.0b3 and Nightly v106.0a1.