Closed
Bug 1081992
Opened 10 years ago
Closed 10 years ago
Crash in mozilla::TextComposition::OnCompositionEventDiscarded(mozilla::WidgetCompositionEvent const*)
Categories
(Core :: DOM: Events, defect)
Tracking
()
VERIFIED
FIXED
mozilla36
Tracking | Status | |
---|---|---|
firefox34 | --- | unaffected |
firefox35 | --- | fixed |
firefox36 | --- | fixed |
People
(Reporter: alice0775, Assigned: masayuki)
References
Details
(4 keywords)
Crash Data
Attachments
(1 file)
1.38 KB,
patch
|
smaug
:
review+
Sylvestre
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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•10 years ago
|
Flags: needinfo?(masayuki)
Reporter | ||
Comment 1•10 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*)
Assignee | ||
Comment 2•10 years ago
|
||
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.
Assignee | ||
Comment 3•10 years ago
|
||
(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•10 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:
--- → ?
Assignee | ||
Comment 5•10 years ago
|
||
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 | ||
Comment 6•10 years ago
|
||
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*)
Assignee | ||
Updated•10 years ago
|
Keywords: regression
Updated•10 years ago
|
Attachment #8504487 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 7•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/a19c2e8143cb
https://hg.mozilla.org/mozilla-central/rev/a19c2e8143cb
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Assignee | ||
Comment 9•10 years ago
|
||
Alice-san, could you verify this? After that, I'll request approval for Aurora.
Reporter | ||
Comment 11•10 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)
Assignee | ||
Updated•10 years ago
|
status-firefox36:
--- → fixed
Assignee | ||
Comment 13•10 years ago
|
||
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?
Updated•10 years ago
|
Attachment #8504487 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•10 years ago
|
tracking-firefox35:
? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•