Crash in mozilla::TextComposition::OnCompositionEventDiscarded(mozilla::WidgetCompositionEvent const*)

VERIFIED FIXED in Firefox 35

Status

()

Core
DOM: Events
--
critical
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Alice0775 White, Assigned: masayuki)

Tracking

(4 keywords)

35 Branch
mozilla36
x86
Windows NT
crash, inputmethod, regression, reproducible
Points:
---

Firefox Tracking Flags

(firefox34 unaffected, firefox35 fixed, firefox36 fixed)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
This bug was filed from the Socorro interface and is 
report bp-37a8c712-7890-4d05-afae-c71312141013 .
       bp-40e05000-e439-4923-beb2-60dcb2141013 
=============================================================

This crash happens on Wndows7 and Windows8.
Using :
Microsoft Office IME 2010 on Windows7SP1 x64
Microsoft IME on Windows8.1 x64

Steps To Reproduce:
1. Set intl.tsf.enable = false and Restart browser
2. Click textbox (E.g. SearchBar), Turn on IME
3. Type moji and conversion to open candidate window
4. Click [x] button of window contorols button at the top-right corner, while candidate window still is opened

Actual Results:
Browser crashes:
(Reporter)

Updated

3 years ago
Flags: needinfo?(masayuki)
(Reporter)

Comment 1

3 years ago
bp-507af762-7371-4088-90c3-e0d552141013

Atok2014(trial version) on Windows8.1 x64 crashes with intl.tsf.enable = true.
the crash happens regardless of setting of intl.tsf.enable.
Summary: [TSF]crash in mozilla::TextComposition::OnCompositionEventDiscarded(mozilla::WidgetCompositionEvent const*), if Set intl.tsf.enable = false → [TSF]crash in mozilla::TextComposition::OnCompositionEventDiscarded(mozilla::WidgetCompositionEvent const*)
Looks odd. I don't understand the reason why the TextComposition instance was already destroyed.

We don't do null check here,
http://hg.mozilla.org/mozilla-central/annotate/44168a7af20d/dom/events/IMEStateManager.cpp#l982
but if it's null, it should be crash in IMEStateManager. I'll check the actual behavior at crash tomorrow.
(In reply to Alice0775 White from comment #1)
> the crash happens regardless of setting of intl.tsf.enable.

Yeah, it should be.
Flags: needinfo?(masayuki)
(Reporter)

Comment 4

3 years ago
[Tracking Requested - why for this release]: Crashed by regression of Bug 1065835

Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/11fc11a90d6b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140925165440
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/73b8079308bd
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 ID:20140925170540
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=11fc11a90d6b&tochange=73b8079308bd

Regressed by: Bug 1065835
Blocks: 1065835
status-firefox34: --- → unaffected
status-firefox35: --- → affected
tracking-firefox35: --- → ?
Created attachment 8504487 [details] [diff] [review]
Patch

Oh, the method which is addressed from nullptr is performed! I think that it should be checked even in release build if it's really a bug check, e.g.,if arguments have nullptrs.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attachment #8504487 - Flags: review?(bugs)
I'm not sure why this bug can be reproduced only with the last window at closing it. I.e., I cannot reproduce this bug when two or more windows are open.
Summary: [TSF]crash in mozilla::TextComposition::OnCompositionEventDiscarded(mozilla::WidgetCompositionEvent const*) → Crash in mozilla::TextComposition::OnCompositionEventDiscarded(mozilla::WidgetCompositionEvent const*)
Keywords: regression

Updated

3 years ago
Attachment #8504487 - Flags: review?(bugs) → review+
https://hg.mozilla.org/mozilla-central/rev/a19c2e8143cb
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Alice-san, could you verify this? After that, I'll request approval for Aurora.
Oops, see the previous comment.
Flags: needinfo?(alice0775)
(Reporter)

Comment 11

3 years ago
I cannot reproduce the crash any more on windows7 and windows8.1.

https://hg.mozilla.org/mozilla-central/rev/62f0b771583c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141015030202

https://hg.mozilla.org/mozilla-central/rev/62f0b771583c
Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141015030202
Flags: needinfo?(alice0775)
Thank you, Alice-san.
Status: RESOLVED → VERIFIED
status-firefox36: --- → fixed
Comment on attachment 8504487 [details] [diff] [review]
Patch

Approval Request Comment
[Feature/regressing bug #]: bug 1065835
[User impact if declined]: Use may meet this crash, but the STR is a rare case, I think.
[Describe test coverage new/current, TBPL]: Tested manually because we have no API to test this automatically.
[Risks and why]: This just adds null check before using a pointer. So, there is no risk.
[String/UUID change made/needed]: Nothing.
Attachment #8504487 - Flags: approval-mozilla-aurora?
Attachment #8504487 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
tracking-firefox35: ? → ---
You need to log in before you can comment on or make changes to this bug.