[Tracking Requested - why for this release]: There is a caret display problem in major email composing in Japan.

Steps to reproduce:

1. Open https://mail.yahoo.co.jp/ and login
2. Click メール作成 button
3. Click on the mail body of the compose pane
   --- no caret is shown -- BUG!
4. Type text
   --- still no caret is shown -- BUG!

Actual Results:
No caret is shown.

Expected Results:
Caret should be shown properly

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1e0fa73ae80e4cfa634f47766224a5d256e6c735&tochange=5d866154c49f0153af2df3cbfd1d087e343fc49f

:masayuki, since you are the author of the regressor, bug 1770874, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Oh, couldn't it narrow the range to each commit? Sigh...

I'm not sure how Selection.addRange is called in the Yahoo! Japan Mail, though.

2023-06-29 03:28:34.705000 UTC - [Child 61920: Main Thread]: I/SelectionAPI 1d36e583900 Selection::AddRangeJS(aRange={ mStart=mEnd={ mParent=000001D37027C780 (#text.span.span.p.div[contenteditable="true"].div.div['composeScrollArea1_1688009305761'].div.div.div.div.div.div.div.div['root'].body.html.#document, Length()=1), mRef=null, mOffset=1, mIsMutationObserved=true }, mIsGenerated=false, mCalledByJS=true, mIsDynamicRange=true })
2023-06-29 03:28:34.705000 UTC - [Child 61920: Main Thread]: V/SelectionAPI
#01: mozilla::dom::Selection::AddRangeJS (M:\src\dom\base\Selection.cpp:2146)
#02: mozilla::dom::Selection_Binding::addRange (M:\fx64-dbg\dom\bindings\SelectionBinding.cpp:355)
#03: mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy,mozilla::dom::binding_detail::ThrowExceptions> (M:\src\dom\bindings\BindingUtils.cpp:3329)
#04: CallJSNative (M:\src\js\src\vm\Interpreter.cpp:486)
#05: js::InternalCallOrConstruct (M:\src\js\src\vm\Interpreter.cpp:580)
#06: js::Interpret (M:\src\js\src\vm\Interpreter.cpp:3395)
#07: js::RunScript (M:\src\js\src\vm\Interpreter.cpp:458)
#08: js::InternalCallOrConstruct (M:\src\js\src\vm\Interpreter.cpp:612)
#09: js::Call (M:\src\js\src\vm\Interpreter.cpp:679)
#10: js::fun_call (M:\src\js\src\vm\JSFunction.cpp:956)
#11: CallJSNative (M:\src\js\src\vm\Interpreter.cpp:486)
#12: js::InternalCallOrConstruct (M:\src\js\src\vm\Interpreter.cpp:580)
#13: js::Interpret (M:\src\js\src\vm\Interpreter.cpp:3395)
#14: js::RunScript (M:\src\js\src\vm\Interpreter.cpp:458)
#15: js::InternalCallOrConstruct (M:\src\js\src\vm\Interpreter.cpp:612)
#16: js::Call (M:\src\js\src\vm\Interpreter.cpp:679)
#17: js::fun_call (M:\src\js\src\vm\JSFunction.cpp:956)
#18: CallJSNative (M:\src\js\src\vm\Interpreter.cpp:486)
#19: js::InternalCallOrConstruct (M:\src\js\src\vm\Interpreter.cpp:580)
#20: js::jit::DoCallFallback (M:\src\js\src\jit\BaselineIC.cpp:1591)
#21: ??? (???:???)

This is for Selection of the document (i.e., shared with selection in <div contenteditable>.

2023-06-29 03:28:34.734000 UTC - [Child 61920: Main Thread]: I/SelectionAPI 1d3711ee120 Selection::SetAncestorLimiter(aLimiter=nullptr)
2023-06-29 03:28:34.734000 UTC - [Child 61920: Main Thread]: V/SelectionAPI
#01: mozilla::dom::Selection::SetAncestorLimiter (M:\src\dom\base\Selection.cpp:1978)
#02: mozilla::EditorBase::FinalizeSelection (M:\src\editor\libeditor\EditorBase.cpp:5493)
#03: mozilla::TextEditor::OnBlur (M:\src\editor\libeditor\TextEditor.cpp:759)
#04: mozilla::EditorEventListener::HandleEvent (M:\src\editor\libeditor\EditorEventListener.cpp:456)
#05: mozilla::EventListenerManager::HandleEventSubType (M:\src\dom\events\EventListenerManager.cpp:1254)
#06: mozilla::EventListenerManager::HandleEventInternal (M:\src\dom\events\EventListenerManager.cpp:1443)
#07: mozilla::EventTargetChainItem::HandleEvent (M:\src\dom\events\EventDispatcher.cpp:345)
#08: mozilla::EventTargetChainItem::HandleEventTargetChain (M:\src\dom\events\EventDispatcher.cpp:536)
#09: mozilla::EventTargetChainItem::HandleEventTargetChain (M:\src\dom\events\EventDispatcher.cpp:645)
#10: mozilla::EventDispatcher::Dispatch (M:\src\dom\events\EventDispatcher.cpp:1152)
#11: FocusBlurEvent::Run (M:\src\dom\base\nsFocusManager.cpp:2741)
#12: nsContentUtils::AddScriptRunner (M:\src\dom\base\nsContentUtils.cpp:6070)
#13: nsContentUtils::AddScriptRunner (M:\src\dom\base\nsContentUtils.cpp:6076)
#14: nsFocusManager::FireFocusOrBlurEvent (M:\src\dom\base\nsFocusManager.cpp:2895)
#15: nsFocusManager::SendFocusOrBlurEvent (M:\src\dom\base\nsFocusManager.cpp:2855)
#16: nsFocusManager::BlurImpl (M:\src\dom\base\nsFocusManager.cpp:2396)
#17: nsFocusManager::Blur (M:\src\dom\base\nsFocusManager.cpp:2199)
#18: nsFocusManager::SetFocusInner (M:\src\dom\base\nsFocusManager.cpp:1789)
#19: nsFocusManager::SetFocus (M:\src\dom\base\nsFocusManager.cpp:476)
#20: mozilla::EventStateManager::PostHandleEvent (M:\src\dom\events\EventStateManager.cpp:3507)
#21: mozilla::PresShell::EventHandler::DispatchEvent (M:\src\layout\base\PresShell.cpp:8261)
#22: mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo (M:\src\layout\base\PresShell.cpp:8182)
#23: mozilla::PresShell::EventHandler::HandleEventUsingCoordinates (M:\src\layout\base\PresShell.cpp:7128)
#24: mozilla::PresShell::EventHandler::HandleEvent (M:\src\layout\base\PresShell.cpp:6926)
#25: mozilla::PresShell::HandleEvent (M:\src\layout\base\PresShell.cpp:6869)
#26: nsViewManager::DispatchEvent (M:\src\view\nsViewManager.cpp:652)
#27: nsView::HandleEvent (M:\src\view\nsView.cpp:1150)
#28: mozilla::widget::PuppetWidget::DispatchEvent (M:\src\widget\PuppetWidget.cpp:347)
#29: mozilla::layers::APZCCallbackHelper::DispatchWidgetEvent (M:\src\gfx\layers\apz\util\APZCCallbackHelper.cpp:508)
#30: mozilla::dom::BrowserChild::HandleRealMouseButtonEvent (M:\src\dom\ipc\BrowserChild.cpp:1663)
#31: mozilla::dom::BrowserChild::ProcessPendingCoalescedMouseDataAndDispatchEvents (M:\src\dom\ipc\BrowserChild.cpp:1492)
#32: mozilla::dom::BrowserChild::RecvRealMouseButtonEvent (M:\src\dom\ipc\BrowserChild.cpp:1625)
#33: mozilla::dom::PBrowserChild::OnMessageReceived (M:\fx64-dbg\ipc\ipdl\PBrowserChild.cpp:5607)
#34: mozilla::dom::PContentChild::OnMessageReceived (M:\fx64-dbg\ipc\ipdl\PContentChild.cpp:8791)
#35: mozilla::ipc::MessageChannel::DispatchAsyncMessage (M:\src\ipc\glue\MessageChannel.cpp:1811)
#36: mozilla::ipc::MessageChannel::DispatchMessage (M:\src\ipc\glue\MessageChannel.cpp:1736)
#37: mozilla::ipc::MessageChannel::RunMessage (M:\src\ipc\glue\MessageChannel.cpp:1536)
#38: mozilla::ipc::MessageChannel::MessageTask::Run (M:\src\ipc\glue\MessageChannel.cpp:1643)
#39: mozilla::RunnableTask::Run (M:\src\xpcom\threads\TaskController.cpp:556)
#40: mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal (M:\src\xpcom\threads\TaskController.cpp:880)
#41: mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal (M:\src\xpcom\threads\TaskController.cpp:704)
#42: mozilla::TaskController::ProcessPendingMTTask (M:\src\xpcom\threads\TaskController.cpp:491)
#43: mozilla::detail::RunnableFunction<`lambda at M:/src/xpcom/threads/TaskController.cpp:221:7'>::Run (M:\src\xpcom\threads\nsThreadUtils.h:549)
#44: nsThread::ProcessNextEvent (M:\src\xpcom\threads\nsThread.cpp:1203)
#45: NS_ProcessNextEvent (M:\src\xpcom\threads\nsThreadUtils.cpp:480)
#46: mozilla::ipc::MessagePump::Run (M:\src\ipc\glue\MessagePump.cpp:107)
#47: MessageLoop::RunHandler (M:\src\ipc\chromium\src\base\message_loop.cc:364)
#48: MessageLoop::Run (M:\src\ipc\chromium\src\base\message_loop.cc:346)
#49: nsBaseAppShell::Run (M:\src\widget\nsBaseAppShell.cpp:150)
#50: nsAppShell::Run (M:\src\widget\windows\nsAppShell.cpp:615)
#51: XRE_RunAppShell (M:\src\toolkit\xre\nsEmbedFunctions.cpp:717)
#52: mozilla::ipc::MessagePumpForChildProcess::Run (M:\src\ipc\glue\MessagePump.cpp:235)
#53: MessageLoop::RunHandler (M:\src\ipc\chromium\src\base\message_loop.cc:364)
#54: MessageLoop::Run (M:\src\ipc\chromium\src\base\message_loop.cc:346)
#55: XRE_InitChildProcess (M:\src\toolkit\xre\nsEmbedFunctions.cpp:656)
#56: NS_internal_main (M:\src\browser\app\nsBrowserApp.cpp:375)
#57: wmain (M:\src\toolkit\xre\nsWindowsWMain.cpp:167)
#58: __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
#59: BaseThreadInitThunk[C:\WINDOWS\System32\KERNEL32.DLL +0x126ad]
#60: RtlUserThreadStart[C:\WINDOWS\SYSTEM32\ntdll.dll +0x5a9f8]

Then, blur event handler of TextEditor for <input> of the "To:" field runs.

EditorBase::FinalizeSelection() has some updating code of caret.
https://searchfox.org/mozilla-central/rev/3b707c8fd7e978eebf24279ee51ccf07895cfbcb/editor/libeditor/EditorBase.cpp#5497-5521

In my understanding caret is shared between TextEditors and the document. Therefore, it's too late to handle it.

Okay, within part. 8, the focus element check done in EditorBase::OnBlur() was not copied to TextEditor::OnBlur().

Alice-san, do you know whether this appears recently in Yahoo! Japan Mail? If so, we may need to uplift the patch for a dot release.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #5)

Alice-san, do you know whether this appears recently in Yahoo! Japan Mail? If so, we may need to uplift the patch for a dot release.

I don't know when this glitch started.

FYI,
Reply, Forward mail and Text mail are not affected. I have been using text mail all along.

Before bug 1770874, EditorBase::OnBlur checked that for both TextEditor
and HTMLEditor. However, accidentally, I removed the check from TextEditor.
Therefore, a call of EditorBase::FinalizeSelection() will hide the caret
even after another editor gets focus.

Therefore, this patch just take it back into TextEditor::OnBlur.

Note that I don't think the design mode handling is required there because
TextEditors shouldn't be created in the design mode document.

Thank you, Alice-san for your report and about the regressed timing check.

I still think that if this appeared by a change of Yahoo! Japan Mail, we should request to uplift for dot release, but currently, we don't have any information about that. Therefore, I think we should request to uplift for ESR 115.

(Workaround: Click blank space of the toolbar, then, click the editor again. Or inactivate the window and activate the window again.)

https://hg.mozilla.org/mozilla-central/rev/0d5974279bf6

Comment on attachment 9341707 [details]
Bug 1840804 - Make TextEditor::OnBlur stop finalizing Selection if new element already gets focus r=m_kato!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a problem in one of the biggest web site in Japan.
• User impact if declined: It's hard to compose email for the email users of Yahoo! Japan because caret won't appear unless using the workaround (comment 10).
• Fix Landed on Version: 116
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Porting the removed code in the regressed path to TextEditor::OnBlur().

The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox115 to wontfix.

For more information, please visit BugBot documentation.

status-firefox115: affected → wontfix

I'll ask uplift to a dot release of 115 because the affected web site is too major web site in Japan and this blocks users to use the mail service.

Comment on attachment 9341707 [details]
Bug 1840804 - Make TextEditor::OnBlur stop finalizing Selection if new element already gets focus r=m_kato!

Approved for 115.1esr

https://hg.mozilla.org/releases/mozilla-esr115/rev/637a2f9a456b

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #14)

status-firefox115: affected → wontfix

I'll ask uplift to a dot release of 115 because the affected web site is too major web site in Japan and this blocks users to use the mail service.

Please add the release uplift request when ready for possible inclusion in a 115 dot release

Comment on attachment 9341707 [details]
Bug 1840804 - Make TextEditor::OnBlur stop finalizing Selection if new element already gets focus r=m_kato!

Beta/Release Uplift Approval Request

• User impact if declined: This is not a recent regression, but this was reported recently and this is a bug in one of most popular web site in Japan. This bug makes it really hard users to compose email in their web UI. Therefore, this may cause users switching default browser.
• 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 is a partial backout of the regressed patch.
• String changes made/needed:
• Is Android affected?: Yes

Comment on attachment 9341707 [details]
Bug 1840804 - Make TextEditor::OnBlur stop finalizing Selection if new element already gets focus r=m_kato!

Approved for 115.0.2
Approved for 115.0.2esr

Unfortunately we don't have access to a Yahoo JP mail account so we can properly verify the fixes. Alice, can you please verify the fixes on the latest builds? Thanks!

I verified that this was fixed on Firefox116.0rc(build id20230724170120), Firefox115.0.2(build id20230710165010) and Firefox115.0.3esr(build id20230718155128) as well as Nightly117.0a1(build id20230725211415).