Crash in [@ mozilla::widget::TSFTextStore::SelectionForTSF]
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
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
Assignee | ||
Comment 2•2 years ago
|
||
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 | ||
Comment 3•2 years ago
|
||
Oops, must be S3 because this is an assertion failure even though it fails in the beta builds.
Assignee | ||
Comment 4•2 years ago
|
||
(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
.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
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.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 7•2 years ago
|
||
bugherder |
Assignee | ||
Comment 8•2 years ago
|
||
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.
Assignee | ||
Comment 9•2 years ago
|
||
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.
Reporter | ||
Comment 10•1 year ago
|
||
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
Assignee | ||
Comment 11•1 year ago
|
||
(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.
Comment 12•10 months ago
|
||
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.
Assignee | ||
Comment 13•10 months ago
|
||
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.
Assignee | ||
Comment 14•9 months ago
|
||
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.
Assignee | ||
Comment 15•9 months ago
|
||
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
Assignee | ||
Comment 16•9 months ago
|
||
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_ASSERT
s 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
Comment 17•9 months ago
|
||
Comment 18•9 months ago
|
||
bugherder |
Comment 19•9 months ago
|
||
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.
Assignee | ||
Comment 20•9 months ago
|
||
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).
Assignee | ||
Comment 21•9 months ago
|
||
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)
Assignee | ||
Comment 22•9 months ago
•
|
||
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.
Comment 23•8 months ago
|
||
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.
Description
•