Closed Bug 1764762 Opened 3 years ago Closed 3 years ago

Crash in [@ mozilla::widget::TSFTextStore::CreateNativeCaret]

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Firefox 99
All
Windows
defect

Tracking

()

VERIFIED FIXED
101 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox99 --- wontfix
firefox100 --- verified
firefox101 --- verified

People

(Reporter: aryx, Assigned: masayuki)

References

(Regression)

Details

(Keywords: crash, inputmethod, regression)

Crash Data

Attachments

(1 file)

Windows crash new in Firefox 99 - 68 crashes from 54 installations of Firefox 99.0/99.0.1. Could this be from the code changes in bug 1746104?

Crash report: https://crash-stats.mozilla.org/report/index/5ed53794-67b6-451a-98bf-e3de30220414

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(isSome())

Top 10 frames of crashing thread:

0 xul.dll mozilla::widget::TSFTextStore::CreateNativeCaret widget/windows/TSFTextStore.cpp:6415
1 xul.dll mozilla::widget::TSFTextStore::OnSelectionChangeInternal widget/windows/TSFTextStore.cpp:6052
2 xul.dll static mozilla::widget::TSFTextStore::OnSelectionChange widget/windows/TSFTextStore.h:183
3 xul.dll static mozilla::widget::IMEHandler::NotifyIME widget/windows/WinIMEHandler.cpp:248
4 xul.dll mozilla::widget::TextEventDispatcher::NotifyIME widget/TextEventDispatcher.cpp:447
5 xul.dll nsBaseWidget::NotifyIME widget/nsBaseWidget.cpp:1696
6 xul.dll static mozilla::IMEStateManager::NotifyIME dom/events/IMEStateManager.cpp:1896
7 xul.dll mozilla::dom::BrowserParent::RecvNotifyIMECompositionUpdate dom/ipc/BrowserParent.cpp:2400
8 xul.dll mozilla::dom::PBrowserParent::OnMessageReceived ipc/ipdl/PBrowserParent.cpp:3571
9 xul.dll mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:7053
Flags: needinfo?(m_kato)

User on reddit: https://www.reddit.com/r/firefox/comments/u2ubjt/leaving_comment_under_a_youtube_video_crashes/ says:

I go to Youtube, leave a comment on a video, and as soon as I publish it, Firefox crashes.

The comment is there when I reload Firefox, but it's still quite annoying.

Could this be from the code changes in bug 1746104?

I guess yes since this is from 99. But I don't know why selectionForTSF is nothing even if we check it before.

Flags: needinfo?(m_kato)

I guess it's the case of no selection. selectionForTSF->mACP must be Nothing in the case.

Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Priority: -- → P1
Regressed by: 1746104
Hardware: Unspecified → All
Version: unspecified → Firefox 99

How can I test this in YouTube before requesting the review? Is there a proper video which is posted by Mozilla?

(Of course, I tried getSelection().removeAllRanges() in various event listeners, but I couldn't reproduce this crash with ATOK 2015 or earlier.)

Has Regression Range: --- → yes

:hsinyi is comment 4 something you can help with?

Flags: needinfo?(htsai)

I succeeded to manage reproduce this bug with running calet.exe in attachment 9022868 [details] (bug 1504963) at posting a comment in https://youtu.be/mLrNPHn3Thc?list=PLnRGhgZaGeBsfa8V-r0inumjIZWlQLQCJ, but I cannot reproduce this with ATOK 2015 nor ATOK 2013.

And verified to fix this with my patch.

Flags: needinfo?(htsai)

selectionForTSF may not have selection range. However, it retrieves max offset
of selection before checking selectionForTSF has a selection range.

Note that this path runs only when there is an a11y tool which require native
caret or the active TIP is ATOK 2011-2015.

Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/1e67a826618d Make `TSFTextStore::CreateNativeCaret` check whether there is selection range before accessing selection offset r=m_kato

Comment on attachment 9272943 [details]
Bug 1764762 - Make TSFTextStore::CreateNativeCaret check whether there is selection range before accessing selection offset r=m_kato!

Beta/Release Uplift Approval Request

  • User impact if declined: The number of this crash report is not few. The victims must use a11y tools which refer native caret on Windows.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: 1. Download attachment 9022868 [details] (bug 1504963)
  1. Run calet.exe in the zip file
  2. Type something into the comment field of YouTube (for example, in a Mozilla's video
  3. Post the comment with Ctrl + Enter
    (5. Delete the comment for making the other users not confused)
  • 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 mistake of handling Maybe member. And the path runs only when the users use Japanese 3rd party's ATOK 2011-2015 or use a11y tools which refer native caret.
  • String changes made/needed: none
Attachment #9272943 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Has the fix been verified in Nightly?: Yes

I meant I verified it in patched build before requesting the review.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch

Comment on attachment 9272943 [details]
Bug 1764762 - Make TSFTextStore::CreateNativeCaret check whether there is selection range before accessing selection offset r=m_kato!

Approved for 100.0b9

Attachment #9272943 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Reproduced the crash on Firefox 101.0a1 (2022-04-14) under Windows 11 by following the STR from Comment 9.

The crash is no longer ocurring on Firefox 100.0 and 101.0a1 (2022-04-26) under the same system.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: