Closed Bug 1117087 Opened 5 years ago Closed 5 years ago

crash in nsEditor::EnsureComposition(mozilla::WidgetGUIEvent*)

Categories

(Core :: DOM: Editor, defect, critical)

All
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox37 --- unaffected
firefox38 --- unaffected
firefox39 + fixed
firefox38.0.5 --- unaffected
firefox40 + fixed

People

(Reporter: nigelb, Assigned: masayuki)

References

Details

(4 keywords)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-78e7a9bb-3cdc-4f69-9746-044592150102.
=============================================================

I can reproduce this consistently by pressing Ctrl + Shift + U in a comment box on Facebook. I was originally starting to type a unicode character.
Heh, amusingly, only reproduced if I try to press Ctrl + Shift + U in an empty comment box. If I have something already in it, it doesn't crash.

Er, yes. I type unicode often.
Component: General → Editor
I've been running into this (also on Facebook, using the right Alt key as Compose), and reproduced it on a debug build.  It looks like IMEStateManager::sTextCompositions is empty, which would explain why nsEditor can't find one:

(gdb) p mozilla::IMEStateManager::sTextCompositions->mHdr->mLength

Running with NSPR_LOG_MODULES=IMEStateManager:5 gives me these messages — and all of this occurs on the *last* keypress of the compose sequence; there are no IMEStateManager messages caused by the earlier keypresses:

ISM: IMEStateManager::DispatchCompositionEvent(aNode=0x7f8ffa68e420, aPresContext=0x7f8fffc2b000, aCompositionEvent={ message=NS_COMPOSITION_START, mFlags={ mIsTrusted=true, mPropagationStopped=false } }, aIsSynthesized=false)
ISM:   IMEStateManager::DispatchCompositionEvent(), adding new TextComposition to the array
ISM: IMEStateManager::DispatchCompositionEvent(aNode=0x7f8ffa68e420, aPresContext=0x7f8fffc2b000, aCompositionEvent={ message=unacceptable event message, mFlags={ mIsTrusted=true, mPropagationStopped=false } }, aIsSynthesized=false)
WARNING: NS_ENSURE_TRUE(mComposition) failed: file /home/jld/src/mozilla-central/editor/libeditor/nsEditor.cpp, line 2033
ISM: IMEStateManager::NotifyIME(aMessage=NOTIFY_IME_OF_COMPOSITION_UPDATE, aPresContext=0x7f8fffc2b000)
ISM: IMEStateManager::NotifyIME(aMessage=NOTIFY_IME_OF_COMPOSITION_UPDATE, aWidget=0x7f900461bf80), composition=0x7f8fef933470, composition->IsSynthesizedForTests()=false
ISM:   IMEStateManager::DispatchCompositionEvent(), removing TextComposition from the array since NS_COMPOSTION_END was dispatched
Hit MOZ_CRASH(IMEStateManager doesn't return proper composition) at /home/jld/src/mozilla-central/editor/libeditor/nsEditor.cpp:2014
(In reply to Jed Davis [:jld] {UTC-7} from comment #2)
> (gdb) p mozilla::IMEStateManager::sTextCompositions->mHdr->mLength

That printed "0"; I accidentally deleted that line while editing the comment.

> ISM: IMEStateManager::DispatchCompositionEvent(aNode=0x7f8ffa68e420,
> aPresContext=0x7f8fffc2b000, aCompositionEvent={ message=unacceptable event
> message, mFlags={ mIsTrusted=true, mPropagationStopped=false } },
> aIsSynthesized=false)

The "unacceptable event message" is 2205 == NS_COMPOSITION_COMMIT.
(In reply to Jed Davis [:jld] {UTC-7} from comment #2)
> ISM:   IMEStateManager::DispatchCompositionEvent(), removing TextComposition
> from the array since NS_COMPOSTION_END was dispatched

It wasn't actually an NS_COMPOSITION_END; that log message is under this condition:

966       if ((!aIsSynthesized ||
967            composition->WasNativeCompositionEndEventDiscarded()) &&
968           aCompositionEvent->CausesDOMCompositionEndEvent()) {

aCompositionEvent->message == NS_COMPOSITION_COMMIT.  composition->mWasNativeCompositionEndEventDiscarded is false, so this condition is true because aIsSynthesized is false.  This is the call stack:

#0  mozilla::IMEStateManager::DispatchCompositionEvent at /home/jld/src/mozilla-central/dom/events/IMEStateManager.cpp:966
#1  0x00007fb23a9e7c74 in PresShell::DispatchEventToDOM at /home/jld/src/mozilla-central/layout/base/nsPresShell.cpp:8150
#2  0x00007fb23a9f559f in PresShell::HandleEventInternal at /home/jld/src/mozilla-central/layout/base/nsPresShell.cpp:8050
#3  0x00007fb23a9f691f in PresShell::HandleEvent at /home/jld/src/mozilla-central/layout/base/nsPresShell.cpp:7768
#4  0x00007fb23a9f6168 in PresShell::HandleEvent at /home/jld/src/mozilla-central/layout/base/nsPresShell.cpp:7314
#5  0x00007fb23a78947a in nsViewManager::DispatchEvent at /home/jld/src/mozilla-central/view/nsViewManager.cpp:776
#6  0x00007fb23a786e4a in nsView::HandleEvent at /home/jld/src/mozilla-central/view/nsView.cpp:1086
#7  0x00007fb23a7b7704 in nsWindow::DispatchEvent at /home/jld/src/mozilla-central/widget/gtk/nsWindow.cpp:490
#8  0x00007fb23a7cd268 in nsGtkIMModule::DispatchCompositionCommitEvent at /home/jld/src/mozilla-central/widget/gtk/nsGtkIMModule.cpp:1216
#9  0x00007fb23a7cd7f0 in nsGtkIMModule::ResetIME at /home/jld/src/mozilla-central/widget/gtk/nsGtkIMModule.cpp:472
#10 0x00007fb23a7b9e88 in nsWindow::NotifyIMEInternal at /home/jld/src/mozilla-central/widget/gtk/nsWindow.cpp:6073
#11 0x00007fb23a289e1b in mozilla::SelectionChangeEvent::Run at /home/jld/src/mozilla-central/dom/events/IMEContentObserver.cpp:338
#12 0x00007fb239a0c42e in nsContentUtils::AddScriptRunner at /home/jld/src/mozilla-central/dom/base/nsContentUtils.cpp:5102
#13 0x00007fb23a27f99a in mozilla::IMEContentObserver::FlushMergeableNotifications at /home/jld/src/mozilla-central/dom/events/IMEContentObserver.cpp:1086
#14 0x00007fb23a27fb2c in mozilla::IMEContentObserver::MaybeNotifyIMEOfSelectionChange at /home/jld/src/mozilla-central/dom/events/IMEContentObserver.cpp:1018
#15 0x00007fb23a283878 in mozilla::IMEContentObserver::NotifySelectionChanged at /home/jld/src/mozilla-central/dom/events/IMEContentObserver.cpp:363
#16 0x00007fb23aa81ef9 in mozilla::dom::Selection::NotifySelectionListeners at /home/jld/src/mozilla-central/layout/generic/nsSelection.cpp:5844
#17 0x00007fb23aa81f5d in nsFrameSelection::NotifySelectionListeners at /home/jld/src/mozilla-central/layout/generic/nsSelection.cpp:2187
#18 0x00007fb23aa8a015 in mozilla::dom::Selection::AddRange at /home/jld/src/mozilla-central/layout/generic/nsSelection.cpp:4655
#19 0x00007fb239e5433c in mozilla::dom::SelectionBinding::addRange at /home/jld/src/mozilla-central/obj-x86_64-unknown-linux-gnu/dom/bindings/SelectionBinding.cpp:485

That's called by JS, and gdb isn't able to follow the stack past the jitcode.
QA Whiteboard: [bugday-20150420]
Keywords: crashreportid
Duplicate of this bug: 1154992
This is a somewhat frequent crash on 39 aurora. It started just after 39 merged so I can't point to a particular change. Ehsan can you help?
Flags: needinfo?(ehsan)
Duplicate of this bug: 1159217
(In reply to David Major [:dmajor] from comment #6)
> This is a somewhat frequent crash on 39 aurora. It started just after 39
> merged so I can't point to a particular change. Ehsan can you help?

This falls into Masayuki's area, since it's IME.
Flags: needinfo?(ehsan) → needinfo?(masayuki)
Duplicate of this bug: 1159105
Hmm, looks like that this is reproduced only on Linux and if it starts with 39, I guess that bug 1143197 is the regression cause. I'll investigate later.
Flags: needinfo?(masayuki)
Hmm, I cannot reproduce this bug with debug build of today's m-c on Ubuntu 15.04...
The Ubuntu version wasn't letting me access about:crashes, so I download a fresh version from Mozilla. Build from 2015-04-30. Tested on Ubuntu 15.10. All I did was start Firefox, go to Facebook, focus on the first comment box of the first post on my newsfeed, and try to input a character using the Compose key (in this case, Compose, '"', '<').

Crash report bp-98b20e1a-0289-4da3-b8ae-22a582150501.
I can reproduce it with Aurora bug I cannot reproduce this with Nightly, sigh...

Perhaps, this bug has been fixed only in Nightly.
Hmm, odd... I failed to reproduce this bug with Aurora again. When I type Ctrl + Shift + U in comment field, the placeholder text is just flicked (not starting to composition). Could some body post a log of nsGtkIMModuleWidgets:5,IMEStateManager:5 with the simplest steps?
And can anybody still reproduce this bug with Nightly? I'm not sure which branches have this bug.
I couldn't reproduce it in Nightly: Compose, dead keys, and Ctrl+Shift+U all work for me.

In Aurora, Ctrl+Shift+U doesn't crash but doesn't start composition, while Compose key (I tested with Compose, '"', '<' and Compose, '.', '.') and dead keys (I tested with "~" followed by "a" in a pt-BR input language) cause the crash if I'm in one of the affected textboxes.
Thank you, David. I guess that this must exist only 39.

However, on my environment, Ctrl + Shift + U doesn't insert 'u' with underline in the comment field. I find the cause. The placeholder text is a text node in contenteditable editor. The node is removed by probably a compositionstart event handler. Then, nsGtkIMModule tries to commit composition with resetting the IM context and dispatches commit string which is empty. However, resetting the IM context is failed (i.e., kept the composition by IME) but Gecko believes there is no composition. This mismatch must cause the crash in 39.

I'll post a patch for it soon and I'll build the patch in 39 branch.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Thank you. I tested Aurora and Nightly x86_64 test builds and I was unable to reproduce this bug.
(In reply to David Santos from comment #19)
> Thank you. I tested Aurora and Nightly x86_64 test builds and I was unable
> to reproduce this bug.

Thank you very much, let's take the patch!
Attached patch PatchSplinter Review
This must be a regression of bug 1143197.

The bug changed nsGtkIMModule::ResetIME() dispatches composition commit event with empty string when there is no composition string.

In the comment field of Facebook is created with contenteditable element and it has placeholder text with a text node which will be removed by compositionstart event.

When user starts composition in the commend field with the placeholder text, Facebook removes the text node from the editor. Then, it causes selection change notification. It causes a call of ResetIME().

Additionally, iBus doesn't cancel composition even if gtk_im_context_reset() is called while it's sending "preedit_start" signal.

I.e., ResetIME() fails to commit composition in IME but Gecko's composition was already commited with empty string. This mismatch causes a call of the MOZ_CRASH().

Temporarily, we should ignore selection change during dispatching NS_COMPOSITION_START because it doesn't cause any problem with nsGtkIMModule if mCompositionStart is modified.

So, you may realized that this patch does NOT fix this bug completely. If compositionstart handler changes focus, the request to commit won't work with iBus. But it must be rare case and it needs larger patch. Therefore, I'd like to fix it in another bug without uplift.
Attachment #8600318 - Flags: review?(m_kato)
[Tracking Requested - why for this release]:

Even if a user won't reproduce this bug, the user cannot start to input text with IME in the comment field of Facebook. This is Linux only and new regression in 39. The suggesting fix isn't so risky because the new path runs only when user meets this special case. However, if we decline this fix, this bug will be inconvenience for our Linux users in such major web service, Facebook.
Attachment #8600318 - Flags: review?(m_kato) → review+
https://hg.mozilla.org/mozilla-central/rev/91f6567c8b9e
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Masayuki, can you request uplift to 39? Thanks!
Flags: needinfo?(masayuki)
Keywords: regression
Comment on attachment 8600318 [details] [diff] [review]
Patch

Approval Request Comment
[Feature/regressing bug #]: bug 1143197
[User impact if declined]: Even if user cannot reproduce the crash, such user cannot input composition string in the commend field of Facebook when the comment field is empty.
[Describe test coverage new/current, TreeHerder]: Already fixed on m-c.
[Risks and why]: Gecko tries to commit composition even when a selection change occurs during dispatching compositionstart but it fails due to iBus's limitation (iBus doesn't stop active composition at sending native compositionstart event). Therefore, Gecko believes composition has already finished but native IME still has composition. When Gecko detects this mismatch, crash itself. This is what is this bug. This patch doesn't cancel composition even if a selection change occurs when compositionstart is being dispatched. So, this patch doesn't effect in most situations. Therefore, the risk is low.
[String/UUID change made/needed]: No.
Flags: needinfo?(masayuki)
Attachment #8600318 - Flags: approval-mozilla-aurora?
Comment on attachment 8600318 [details] [diff] [review]
Patch

Approved for uplift to aurora --  this has had some time on m-c, and fixes a bad regression.
Attachment #8600318 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
It’s back.
Others have already reported it again: https://bugzilla.mozilla.org/show_bug.cgi?id=1170875
Oh, the fix wasn’t released yet? Sorry.
See Also: → 1184890
You need to log in before you can comment on or make changes to this bug.