Open Bug 1840568 Opened 2 years ago Updated 8 months ago

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

Categories

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

Firefox 109
All
Windows 10
defect

Tracking

()

ASSIGNED

People

(Reporter: wsmwk, Assigned: masayuki)

References

Details

(Keywords: crash, inputmethod, leave-open, Whiteboard: [tbird crash])

Crash Data

Attachments

(4 files)

Crash report: https://crash-stats.mozilla.org/report/index/f5e19aae-03bf-4997-af87-667830230626

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(mSelectionForTSF.isNothing()) (How was it initialized recursively?)

Top 10 frames of crashing thread:

0  xul.dll  mozilla::widget::TSFTextStore::SelectionForTSF  widget/windows/TSFTextStore.cpp:2902
1  xul.dll  mozilla::widget::TSFTextStore::GetSelection  widget/windows/TSFTextStore.cpp:2737
2  textinputframework.dll  CACPWrap::GetSelection  
3  textinputframework.dll  CInputContext::GetSelection  
4  textinputframework.dll  CInputContext::_UpdateKeyEventFilterCallback  
5  textinputframework.dll  CInputContext::_PseudoSyncEditSessionQiCallback  
6  textinputframework.dll  CInputContext::OnLockGranted  
7  textinputframework.dll  CACPWrap::OnLockGranted  
8  xul.dll  mozilla::widget::TSFTextStore::RequestLock  widget/windows/TSFTextStore.cpp:2123
9  textinputframework.dll  CInputContext::_QueueItem  

Firefox crashes go back at least to 109.0a1 bp-2b868107-0991-4f12-bd57-b2dca0230102
Thunderbird crash bp-376b5bfa-2b15-4ed6-a336-787040230626

Do you have an idea about this Masayuki?

Flags: needinfo?(masayuki)

Ah, here is also emplaces mSelectionForTSF. If focused element is in the main process and this query flushing layout might cause selection, we may hit the assertion. However, I still don't have an idea how to flush pending IME notifications immediately though.

Assignee: nobody → masayuki
Severity: -- → S2
Status: NEW → ASSIGNED
Flags: needinfo?(masayuki)
Priority: -- → P3
Hardware: Unspecified → All

Oops, must be S3 because this is an assertion failure even though it fails in the beta builds.

Severity: S2 → S3

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #2)

Ah, here is also emplaces mSelectionForTSF. If focused element is in the main process and this query flushing layout might cause selection, we may hit the assertion. However, I still don't have an idea how to flush pending IME notifications immediately though.

Oops, this is impossible because the other mSelectionForTSF setter, NotifyTSFOfSelectionChange, is called only by MaybeFlushPendingNotifications, but it does nothing if mDeferNotifyingTSF is set and it's set in SelectionForTSF with AutoNotifyingTSFBatch.

I still don't understand what causes a recursive call while TSFTextStore
initializes content or selection cache. According to the crash rate, we
can stop doing this before the next merge.

Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/c72e45d16969 Let's collect unexpected cases with diagnostic assertions of initializing `TSFTextStore::mContentForTSF` and `TSFTextStore::mSelectionForTSF` r=m_kato
Crash Signature: [@ mozilla::widget::TSFTextStore::SelectionForTSF] → [@ mozilla::widget::TSFTextStore::SelectionForTSF] [@ mozilla::widget::TSFTextStore::ContentForTSF] [@ mozilla::widget::TSFTextStore::NotifyTSFOfSelectionChange]

Okay, we got this:

mozilla::widget::TSFTextStore::SelectionForTSF()	widget/windows/TSFTextStore.cpp:2899
mozilla::widget::TSFTextStore::CreateNativeCaret()	widget/windows/TSFTextStore.cpp:6437
mozilla::widget::TSFTextStore::OnSelectionChangeInternal(mozilla::widget::IMENotification const&)	widget/windows/TSFTextStore.cpp:6085
mozilla::widget::TSFTextStore::OnSelectionChange(mozilla::widget::IMENotification const&)	widget/windows/TSFTextStore.h:183
mozilla::widget::IMEHandler::NotifyIME(nsWindow*, mozilla::widget::IMENotification const&)	widget/windows/WinIMEHandler.cpp:244
mozilla::widget::TextEventDispatcher::NotifyIME(mozilla::widget::IMENotification const&)	widget/TextEventDispatcher.cpp:486
nsBaseWidget::NotifyIME(mozilla::widget::IMENotification const&)	widget/nsBaseWidget.cpp:1901
mozilla::IMEStateManager::NotifyIME(mozilla::widget::IMENotification const&, nsIWidget*, mozilla::dom::BrowserParent*)	dom/events/IMEStateManager.cpp:2123
mozilla::IMEContentObserver::IMENotificationSender::SendSelectionChange()	dom/events/IMEContentObserver.cpp:1924
mozilla::IMEContentObserver::IMENotificationSender::Run()	dom/events/IMEContentObserver.cpp:1747
mozilla::IMEContentObserver::TryToFlushPendingNotifications(bool)	dom/events/IMEContentObserver.cpp:1537
mozilla::EventStateManager::TryToFlushPendingNotificationsToIME()	dom/events/EventStateManager.cpp:495
mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo(mozilla::WidgetEvent*, nsEventStatus*, bool, nsIContent*)	layout/base/PresShell.cpp:8188
mozilla::PresShell::EventHandler::HandleEventAtFocusedContent(mozilla::WidgetGUIEvent*, nsEventStatus*)	layout/base/PresShell.cpp:7926
mozilla::PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*)	layout/base/PresShell.cpp:6870
nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*)	view/nsViewManager.cpp:653
nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool)	view/nsView.cpp:1149
nsWindow::DispatchEvent(mozilla::WidgetGUIEvent*, nsEventStatus&)	widget/windows/nsWindow.cpp:4387
nsBaseWidget::DispatchWindowEvent(mozilla::WidgetGUIEvent&)	widget/nsBaseWidget.cpp:1323
mozilla::widget::TSFTextStore::DispatchEvent(mozilla::WidgetGUIEvent&)	widget/windows/TSFTextStore.cpp:2209
mozilla::widget::TSFTextStore::SelectionForTSF()	widget/windows/TSFTextStore.cpp:2911
mozilla::widget::TSFTextStore::GetSelection(unsigned long, unsigned long, TS_SELECTION_ACP*, unsigned long*)	widget/windows/TSFTextStore.cpp:2737 

The call of TSFTextStore::CreateNativeCaret() is wrong. It should be done in TSFTextStore::NotifyTSFOfSelectionChange() I think.

Oh, and also we got this.

mozilla::widget::TSFTextStore::SelectionForTSF()	widget/windows/TSFTextStore.cpp:2899
mozilla::widget::TSFTextStore::GetSelection(unsigned long, unsigned long, TS_SELECTION_ACP*, unsigned long*)	widget/windows/TSFTextStore.cpp:2737
CACPWrap::GetSelection(unsigned long, unsigned long, TS_SELECTION_ANCHOR*, unsigned long*)	
CInputContext::GetSelection(unsigned long, unsigned long, unsigned long, TF_SELECTION*, unsigned long*)	
CInputContext::IsVerticalWriting(void)	
CInputContextAdapter::OnFocusChange(bool, IAdaptedInputContext*)	
CDocumentInputManager::OnFocusChange(bool)	
CThreadInputMgr::_SetFocus(IDocumentInputManagerPrivate*, int)	
CThreadInputMgr::OnInputFocusEvent(unsigned long, HWND__*, long, long, unsigned long, unsigned long)	
CThreadInputMgr::OnCiceroEvent(unsigned long, HWND__*, long, long, unsigned long, unsigned long)	
WinEventProc(HWINEVENTHOOK__*, unsigned long, HWND__*, long, long, unsigned long, unsigned long)	
_ClientCallWinEventProc	
KiUserCallbackDispatch	
NtUserShowWindow	
nsWindow::Show(bool)	widget/windows/nsWindow.cpp:1820
nsView::DoResetWidgetBounds(bool, bool)	view/nsView.cpp:333
nsView::ResetWidgetBounds(bool, bool)	view/nsView.cpp:192
nsViewManager::ProcessPendingUpdatesForView(nsView*, bool)	view/nsViewManager.cpp:315
mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush)	layout/base/PresShell.cpp:4373
mozilla::PresShell::FlushPendingNotifications(mozilla::ChangesToFlush)	layout/base/PresShell.h:1464
mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush)	dom/base/Document.cpp:10914
mozilla::dom::Document::FlushPendingNotifications(mozilla::FlushType)	dom/base/Document.cpp:10846
mozilla::ContentEventHandler::InitBasic(bool)	dom/events/ContentEventHandler.cpp:258
mozilla::ContentEventHandler::InitCommon(mozilla::EventMessage, mozilla::SelectionType, bool)	dom/events/ContentEventHandler.cpp:331
mozilla::ContentEventHandler::Init(mozilla::WidgetQueryContentEvent*)	dom/events/ContentEventHandler.cpp:403
mozilla::ContentEventHandler::OnQuerySelectedText(mozilla::WidgetQueryContentEvent*)	dom/events/ContentEventHandler.cpp:1384
mozilla::ContentEventHandler::HandleQueryContentEvent(mozilla::WidgetQueryContentEvent*)	dom/events/ContentEventHandler.cpp:1315
mozilla::IMEContentObserver::HandleQueryContentEvent(mozilla::WidgetQueryContentEvent*)	dom/events/IMEContentObserver.cpp:664
mozilla::EventStateManager::HandleQueryContentEvent(mozilla::WidgetQueryContentEvent*)	dom/events/EventStateManager.cpp:1160
mozilla::EventStateManager::PreHandleEvent(nsPresContext*, mozilla::WidgetEvent*, nsIFrame*, nsIContent*, nsEventStatus*, nsIContent*)	dom/events/EventStateManager.cpp:698
mozilla::PresShell::EventHandler::DispatchEvent(mozilla::EventStateManager*, mozilla::WidgetEvent*, bool, nsEventStatus*, nsIContent*)	layout/base/PresShell.cpp:8210
mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo(mozilla::WidgetEvent*, nsEventStatus*, bool, nsIContent*)	layout/base/PresShell.cpp:8179
mozilla::PresShell::EventHandler::HandleEventAtFocusedContent(mozilla::WidgetGUIEvent*, nsEventStatus*)	layout/base/PresShell.cpp:7925
mozilla::PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*)	layout/base/PresShell.cpp:6869
nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*)	view/nsViewManager.cpp:653
nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool)	view/nsView.cpp:1149
nsWindow::DispatchEvent(mozilla::WidgetGUIEvent*, nsEventStatus&)	widget/windows/nsWindow.cpp:4387
nsBaseWidget::DispatchWindowEvent(mozilla::WidgetGUIEvent&)	widget/nsBaseWidget.cpp:1323
mozilla::widget::TSFTextStore::DispatchEvent(mozilla::WidgetGUIEvent&)	widget/windows/TSFTextStore.cpp:2209
mozilla::widget::TSFTextStore::SelectionForTSF()	widget/windows/TSFTextStore.cpp:2911
mozilla::widget::TSFTextStore::GetSelection(unsigned long, unsigned long, TS_SELECTION_ACP*, unsigned long*)	widget/windows/TSFTextStore.cpp:2737
CACPWrap::GetSelection(unsigned long, unsigned long, TS_SELECTION_ANCHOR*, unsigned long*)	
CInputContext::GetSelection(unsigned long, unsigned long, unsigned long, TF_SELECTION*, unsigned long*)	
CInputContext::GetSelection(unsigned long, EditControlRange*)	
CInputContextAdapter::_GetCurrentSelection(unsigned long, EditControlRange*)	
CInputContextAdapter::OnEditSessionEnded(unsigned long, ITfEditRecord*, bool)	
CInputContext::_NotifyEndEdit	
CInputContext::OnLockGranted(unsigned long)	
CACPWrap::OnLockGranted(unsigned long)	
mozilla::widget::TSFTextStore::RequestLock(unsigned long, HRESULT*)	widget/windows/TSFTextStore.cpp:2123
CACPWrap::OnTextChange(unsigned long, TS_TEXTCHANGE const*)	
mozilla::widget::TSFTextStore::NotifyTSFOfTextChange()	widget/windows/TSFTextStore.cpp:6043 

This is trickier than the previous one. First call is during notifying TSF of text change. Then, flushing layout causes showing another window. This is really bad. I think that before notifying TSF, we should make TSFTextStore cache everything and stop dispatching query content event.

Also signature OOM | unknown | TerminateProcessOnMemoryExhaustion - 5 of the 6 crashes I randomly picked involve TextInputFramework.dll

Many are startup crashes.

bp-d8ee7866-9e48-4ab7-bab8-920fe0230911
bp-aaef411e-af19-422f-a63b-853b10230907
bp-acc7a401-2944-44f7-baa9-eb3a80231019

Flags: needinfo?(masayuki)

(In reply to Wayne Mery (:wsmwk) from comment #10)

Also signature OOM | unknown | TerminateProcessOnMemoryExhaustion - 5 of the 6 crashes I randomly picked involve TextInputFramework.dll

Many are startup crashes.

bp-d8ee7866-9e48-4ab7-bab8-920fe0230911
bp-aaef411e-af19-422f-a63b-853b10230907
bp-acc7a401-2944-44f7-baa9-eb3a80231019

The OOM reports should not be our issue because their stack do not contain xul.dll. TSF is always internally enabled in Windows (IIRC, starting from Win Vista). Therefore, the module is initialized before TSFTextStore starts working. E.g., bp-acc7a401-2944-44f7-baa9-eb3a80231019 let us know that the initialization runs when the window gets focus.

Flags: needinfo?(masayuki)

The leave-open keyword is there and there is no activity for 6 months.
:masayuki, maybe it's time to close this bug?
For more information, please visit BugBot documentation.

Flags: needinfo?(masayuki)

Interesting, most remaining crash is caused by this call. I think that if it's called while mIsInitializingSelectionForTSF is true, it should set a flag to create native caret at end of TSFTextStore::SelectionForTSF() if it's the topmost setter of the flag.

Flags: needinfo?(masayuki)

Query content is used for a part of handling user interaction with IME or
query request from IME via native API. Therefore, we don't need to flush
pending things at that time since it's not the last chance to do so before
handling next user input. Additionally, the call may cause same query before
returning the result to IME so that may cause stack overflow crash and
that means we flush layout even if the query request does not want flushing
pending things. Therefore, we should not do that at handling query content
event.

It requires selection, but it may be called during SelectionRef() is called
by another method. In that case, it should do nothing and SelectionRef()
should call CreateNativeCaret when it gets the result.

Depends on D209990

By default, query content allows to flushing layout. In most cases, this should
not cause recursive call of the caching content/selection methods. However,
according to a crash report, this may occur with no chance to avoid the loop
from TSFTextStore point of view. Fortunately, the recursive call may happen
only when an element in chrome in the main process has focus. Therefore, I
think that we can keep current MOZ_DIAGNOSTIC_ASSERTs in the methods, but the
nested call should not allow to flush pending layout to avoid an infinite loop
in the release channel.

Depends on D209991

Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/f2cf519ab190 Make `PresShell::HandleEventWithCurrentEventInfo` never try to flush pending things if it handled a query content event r=smaug https://hg.mozilla.org/integration/autoland/rev/a2f3feb68451 Make `TSFTextStore::CreateNativeCaret` put off to creating the native caret if called during querying the selection r=m_kato https://hg.mozilla.org/integration/autoland/rev/d06a74451593 Make `TSFTextStore` allow to flush layout at query content only when it's not called recursively r=m_kato

The bug is linked to a topcrash signature, which matches the following criterion:

  • Top 20 desktop browser crashes on beta

:masayuki, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Flags: needinfo?(masayuki)
Keywords: topcrash

The follow up patches were landed on Nightly and there is no crash report in the Nightly channel. So, I think we can keep this as-is (and I guess that now, this bug is fixed).

Flags: needinfo?(masayuki)

Well, only bp-7513b65a-c37c-4037-9513-6e3500240525 is reported even after the last landing. According to the line of mozilla::dom::XULButtonElement::PostHandleEventForMenus(mozilla::EventChainPostVisitor&) dom/xul/XULButtonElement.cpp:426 in the report, the crash occurred during a right button up on a XUL button. According to this stack:

nsXULPopupManager::HidePopupsInList(nsTArray<nsMenuPopupFrame*> const&)	layout/xul/nsXULPopupManager.cpp:1501
nsXULPopupManager::HideOpenMenusBeforeExecutingMenu(CloseMenuMode)	layout/xul/nsXULPopupManager.cpp:1585
nsXULPopupManager::ExecuteMenu(nsIContent*, nsXULMenuCommandEvent*)	layout/xul/nsXULPopupManager.cpp:1591
mozilla::dom::XULButtonElement::PassMenuCommandEventToPopupManager()	dom/xul/XULButtonElement.cpp:270
mozilla::dom::XULButtonElement::StartBlinking()	dom/xul/XULButtonElement.cpp:280
mozilla::dom::XULButtonElement::ExecuteMenu(mozilla::WidgetEvent&)	dom/xul/XULButtonElement.cpp:341
mozilla::dom::XULButtonElement::PostHandleEventForMenus(mozilla::EventChainPostVisitor&)	dom/xul/XULButtonElement.cpp:426 

It's a menu item rather than a button widget?

Then, editable element gets focus due to the menu lost the pseudo focus.

mozilla::widget::TSFTextStore::CreateAndSetFocus(nsWindow*, mozilla::widget::InputContext const&)	widget/windows/TSFTextStore.cpp:5980
mozilla::widget::TSFTextStore::OnFocusChange(bool, nsWindow*, mozilla::widget::InputContext const&)	widget/windows/TSFTextStore.cpp:5866
mozilla::widget::TSFTextStore::SetInputContext(nsWindow*, mozilla::widget::InputContext const&, mozilla::widget::InputContextAction const&)	widget/windows/TSFTextStore.cpp:6808
mozilla::widget::IMEHandler::SetInputContext(nsWindow*, mozilla::widget::InputContext&, mozilla::widget::InputContextAction const&)	widget/windows/WinIMEHandler.cpp:455
nsWindow::SetInputContext(mozilla::widget::InputContext const&, mozilla::widget::InputContextAction const&)	widget/windows/nsWindow.cpp:7272
mozilla::IMEStateManager::SetInputContext(nsIWidget&, mozilla::widget::InputContext const&, mozilla::widget::InputContextAction const&)	dom/events/IMEStateManager.cpp:1869
mozilla::IMEStateManager::SetIMEState(mozilla::widget::IMEState const&, nsPresContext const*, mozilla::dom::Element*, nsIWidget&, mozilla::widget::InputContextAction, mozilla::widget::InputContext::Origin)	dom/events/IMEStateManager.cpp:1853
mozilla::IMEStateManager::OnChangeFocusInternal(nsPresContext*, mozilla::dom::Element*, mozilla::widget::InputContextAction)	dom/events/IMEStateManager.cpp:740
mozilla::IMEStateManager::SetMenubarPseudoFocus(mozilla::PseudoFocusChangeRunnable*, bool, nsPresContext*)	dom/events/IMEStateManager.cpp:822 

Then, we notify a layout change to Google Japanese Input. Then, they queries the content text and TSFTextStore dispatches eQueryTextContent event. That causes ContentEventHandler flushes pending notifications and that caused showing a window?

CThreadInputMgr::OnCiceroEvent(unsigned long, HWND__*, long, long, unsigned long, unsigned long)
WinEventProc(HWINEVENTHOOK__*, unsigned long, HWND__*, long, long, unsigned long, unsigned long)
_ClientCallWinEventProc
KiUserCallbackDispatch	
NtUserMessageCall
RealDefWindowProcWorker(tagWND*, unsigned int, uint64_t, int64_t, unsigned long)
DefWindowProcW
UserCallWinProcCheckWow(_ACTIVATION_CONTEXT*, int64_t (*)(tagWND*, unsigned int, uint64_t, int64_t), HWND__*, _WM_VALUE, uint64_t, int64_t, void*, int)
CallWindowProcW
nsWindow::WindowProcInternal(HWND__*, unsigned int, unsigned long long, long long)
CallWindowProcCrashProtected(long long (*)(HWND__*, unsigned int, unsigned long long, long long), HWND__*, unsigned int, unsigned long long, long long)
nsWindow::WindowProc(HWND__*, unsigned int, unsigned long long, long long)
UserCallWinProcCheckWow(_ACTIVATION_CONTEXT*, int64_t (*)(tagWND*, unsigned int, uint64_t, int64_t), HWND__*, _WM_VALUE, uint64_t, int64_t, void*, int)
DispatchClientMessage
_fnDWORD
KiUserCallbackDispatch
ZwUserShowWindow
SrHook_ShowWindow
nsWindow::Show(bool)
nsView::DoResetWidgetBounds(bool, bool)
nsView::ResetWidgetBounds(bool, bool)
nsViewManager::ProcessPendingUpdatesForView(nsView*, bool)
mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush)
mozilla::widget::TSFTextStore::CreateAndSetFocus(nsWindow*, mozilla::widget::InputContext const&)	widget/windows/TSFTextStore.cpp:5980
mozilla::widget::TSFTextStore::OnFocusChange(bool, nsWindow*, mozilla::widget::InputContext const&)	widget/windows/TSFTextStore.cpp:5866
mozilla::widget::TSFTextStore::SetInputContext(nsWindow*, mozilla::widget::InputContext const&, mozilla::widget::InputContextAction const&)	widget/windows/TSFTextStore.cpp:6808
mozilla::widget::IMEHandler::SetInputContext(nsWindow*, mozilla::widget::InputContext&, mozilla::widget::InputContextAction const&)	widget/windows/WinIMEHandler.cpp:455
nsWindow::SetInputContext(mozilla::widget::InputContext const&, mozilla::widget::InputContextAction const&)	widget/windows/nsWindow.cpp:7272
mozilla::IMEStateManager::SetInputContext(nsIWidget&, mozilla::widget::InputContext const&, mozilla::widget::InputContextAction const&)	dom/events/IMEStateManager.cpp:1869
mozilla::IMEStateManager::SetIMEState(mozilla::widget::IMEState const&, nsPresContext const*, mozilla::dom::Element*, nsIWidget&, mozilla::widget::InputContextAction, mozilla::widget::InputContext::Origin)	dom/events/IMEStateManager.cpp:1853
mozilla::IMEStateManager::OnChangeFocusInternal(nsPresContext*, mozilla::dom::Element*, mozilla::widget::InputContextAction)	dom/events/IMEStateManager.cpp:740
mozilla::IMEStateManager::SetMenubarPseudoFocus(mozilla::PseudoFocusChangeRunnable*, bool, nsPresContext*)	dom/events/IMEStateManager.cpp:822 

Finally, TSF requests another query of text content:

mozilla::widget::TSFTextStore::ContentForTSF()
mozilla::widget::TSFTextStore::GetText(long, long, wchar_t*, unsigned long, unsigned long*, TS_RUNINFO*, unsigned long, unsigned long*, long*)
CProcessTextCache::GetText(ITextStoreACP*, long, long, unsigned short*, unsigned long, unsigned long*, TS_RUNINFO*, unsigned long, unsigned long*, long*)
AppTextOffsetForward(ITextStoreACP*, long, long, long*, unsigned long)
Normalize(ITextStoreACP*, long, unsigned long)
CACPWrap::_NormalizeAnchor(CAnchor*)
CAnchorRef::Compare
CInputContext::GetSelection(unsigned long, unsigned long, unsigned long, TF_SELECTION*, unsigned long*)
CInputContext::IsVerticalWriting(void)
CInputContextAdapter::RuntimeClassInitialize(IAdaptedInputContext*, ITextInputClient*)
Microsoft::WRL::Details::MakeAndInitialize<CInputContextAdapter, IDocumentContextSink, IAdaptedInputContext*&, ITextInputClient*>(IDocumentContextSink**, IAdaptedInputContext*&, ITextInputClient*&&)
CInputContextAdapter::CreateInstance(IAdaptedInputContext*, IDocumentContextSink**)
CDocumentInputManager::OnFocusChange(bool)

Ah, we do wrong here. We call ITextStoreACPSink::OnLayoutChange with TS_LC_CREATE and TEXTSTORE_DEFAULT_VIEW. However, we work multiple TSFTextStore with only one "view". Therefore, it seems that we don't need to notify TSF of that.

Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.

For more information, please visit BugBot documentation.

Keywords: topcrash
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: