1140939 - crash in mozilla::widget::IMEInputHandler::InsertTextAsCommittingComposition(NSAttributedString*, _NSRange*)

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Xidorn Quan [:xidorn] UTC+11]

This bug was filed from the Socorro interface and is 
report bp-8672bba0-fe30-4ad3-a4a9-bdc1d2150309.
=============================================================

Comment 1

[Xidorn Quan [:xidorn] UTC+11]

This happens when using vertical writing-mode with contenteditable.

Comment 2

[Jonathan Kew [:jfkthame]]

I've tried using contenteditable in vertical writing mode, and have not run into this at all. Can you reproduce it consistently, or was it a one-off crash? If you have detailed STR, that would be great.

Comment 3

[Xidorn Quan [:xidorn] UTC+11]

It seems that it is neither related to writing-mode nor contenteditable. It can be consistently reproduced with some input method. It's my fault not test it more detailedly, and did an inexact guess.

The steps to reproduce:
1. Load page: data:text/html,<input>
2. Use a Japanese input method and input several kanas
3. Close the window immediately before committing anything

I can reproduce this problem on the builtin Japanese input method of Mac, as well as the Google Japanese input method.

Comment 4

[Jonathan Kew [:jfkthame]]

This looks like a long-standing problem; we end up hitting the MOZ_CRASH in IMEInputHandler::InsertTextAsCommittingComposition because IgnoreIMECommit() is true. Maybe :masayuki understands this code and can look into it?

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Xidorn, could you look for a regression range for your STR?  It's conceivable (though unlikely) your crashes were triggered by my patch for bug 1110888.

Please let us know your results.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I've found two different regression ranges, both of which absolve bug 1110888 (at which I'm greatly relieved).  Here's the one for non-e10s mode:

firefox-2014-12-11-03-02-06-mozilla-central
firefox-2014-12-12-03-02-01-mozilla-central

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0cf461e62ce5&tochange=5288b15d22de

Comment 7

[Steven Michaud [:smichaud] (Retired)]

Here's the regression range for e10s mode:

firefox-2014-09-26-03-02-02-mozilla-central
firefox-2014-09-27-03-02-04-mozilla-central

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9e3d649b80a2&tochange=818f353b7aa6

Comment 8

[Steven Michaud [:smichaud] (Retired)]

The patch for bug 1137229 seems to fix this bug in both e10s mode and non-e10s mode.

I tested with the opt tryserver build from bug 1137229 comment #27:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-7f8185f65f28/try-macosx64/firefox-39.0a1.en-US.mac.dmg

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Steven Michaud from comment #8)
> The patch for bug 1137229 seems to fix this bug in both e10s mode and
> non-e10s mode.

Yeah, the stack suspected the cause.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Fixed by the patch for bug 1137229.