857339 - crash in mozilla::a11y::FocusManager::IsFocused

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect, P5)

Description

[Wayne Mery (:wsmwk)]

this is perhaps related to windows file dialog

This bug was filed from the Socorro interface and is 
report bp-58cf64b3-ac5c-4ab7-b8fa-19f062130322 .
============================================================= 
"Trying to attach an image, had a message that the scrit was busy (whatever that is, please use language I can understand) I locked the laptop as guided, opend it in my name again, tried to attach and it crashed, never had it happen before, any ideas "

0	xul.dll	mozilla::a11y::FocusManager::IsFocused	accessible/src/base/FocusManager.cpp:59
1	xul.dll	Accessible::NativeState	accessible/src/generic/Accessible.cpp:671
2	xul.dll	Accessible::State	accessible/src/generic/Accessible.cpp:1440
3	xul.dll	AccessibleWrap::get_accState	accessible/src/msaa/AccessibleWrap.cpp:468
4	rpcrt4.dll	Invoke	
5	rpcrt4.dll	NdrStubCall2	
6	ole32.dll	NdrpCreateStub	
7	oleaut32.dll	CUnivStubWrapper::Invoke	
8	ole32.dll	SyncStubInvoke	
9	ole32.dll	StubInvoke	
10	ole32.dll	CCtxComChnl::ContextInvoke	
11	ole32.dll	MTAInvoke	
12	ole32.dll	STAInvoke	
13	ole32.dll	AppInvoke	
14	ole32.dll	ComInvokeWithLockAndIPID	
15	ole32.dll	ComInvoke	
16	ole32.dll	ThreadDispatch	
17	ole32.dll	ThreadWndProc	
18	user32.dll	InternalCallWinProc	
19	user32.dll	UserCallWinProcCheckWow	
20	user32.dll	DispatchClientMessage	
21	user32.dll	__fnDWORD	
22	ntdll.dll	KiUserCallbackDispatcher	
23	ntdll.dll	KiUserApcDispatcher	
24	shell32.dll	CDefView::_DoContextMenuPopup	
25	shell32.dll	CDefView::OnSelectionContextMenu	
26	explorerframe.dll	UIItemsView::ShowContextMenu	
27	explorerframe.dll	CItemsView::ShowContextMenu	
28	shell32.dll	CDefView::_DoContextMenu	
29	shell32.dll	CDefView::_OnContextMenu	
30	shell32.dll	CDefView::OnGetTryHarderArray	
31	shell32.dll	CDefView::s_WndProc	
32	user32.dll	InternalCallWinProc	
33	user32.dll	UserCallWinProcCheckWow	
34	user32.dll	CallWindowProcAorW	
35	user32.dll	CallWindowProcW	
36	duser.dll	WndBridge::RawWndProc	
37	user32.dll	InternalCallWinProc	
38	user32.dll	UserCallWinProcCheckWow	
39	user32.dll	DispatchClientMessage	
40	user32.dll	__fnDWORD	
41	ntdll.dll	KiUserCallbackDispatcher	
42	ntdll.dll	KiUserApcDispatcher	
43	user32.dll	RealDefWindowProcW	
44	uxtheme.dll	_ThemeDefWindowProc	
45	uxtheme.dll	ThemeDefWindowProcW	
46	user32.dll	GetRealWindowOwner	
47	explorerframe.dll	ItemLayout::SetSectionCount	
48	user32.dll	InternalCallWinProc	
49	user32.dll	UserCallWinProcCheckWow	
50	user32.dll	CallWindowProcAorW	
51	user32.dll	CallWindowProcW	
52	duser.dll	ExtraInfoWndProc	
53	user32.dll	InternalCallWinProc	
54	user32.dll	UserCallWinProcCheckWow	
55	user32.dll	CallWindowProcAorW	
56	user32.dll	CallWindowProcW	
57	comctl32.dll	CallOriginalWndProc	
58	comctl32.dll	CallNextSubclassProc	
59	comctl32.dll	DefSubclassProc	
60	explorerframe.dll	UIItemsView::_UIItemsViewSubclassProc	
61	explorerframe.dll	UIItemsView::s_UIItemsViewSubclassProc	
62	comctl32.dll	CallNextSubclassProc	
63	comctl32.dll	DefSubclassProc	
64	explorerframe.dll	CToolTipManager::_PropertyToolTipSubclassProc	
65	explorerframe.dll	CToolTipManager::s_PropertyToolTipSubclassProc	
66	comctl32.dll	CallNextSubclassProc	
67	comctl32.dll	DefSubclassProc	
68	comctl32.dll	TTSubclassProc	
69	comctl32.dll	CallNextSubclassProc	
70	comctl32.dll	MasterSubclassProc	
71	user32.dll	InternalCallWinProc	
72	user32.dll	UserCallWinProcCheckWow	
73	user32.dll	DispatchMessageWorker	
74	user32.dll	DispatchMessageW	
75	user32.dll	IsDialogMessageW	
76	user32.dll	DialogBox2	
77	user32.dll	InternalDialogBox	
78	user32.dll	DialogBoxIndirectParamAorW	
79	user32.dll	DialogBoxIndirectParamW	
80	comdlg32.dll	CFileOpenSave::Show	
81	xul.dll	nsFilePicker::ShowFilePicker	widget/windows/nsFilePicker.cpp:968
82	xul.dll	nsFilePicker::ShowW	widget/windows/nsFilePicker.cpp:1059

Comment 1

[alexander :surkov (:asurkov)]

Trev, ideas?

aAccessible->GetNode() shouldn't be null since aAccessible is 'this' that complies with mContent->IsElement() == true.

What does 0xc crash address point to here?

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to alexander :surkov from comment #1)
> Trev, ideas?
> 
> aAccessible->GetNode() shouldn't be null since aAccessible is 'this' that
> complies with mContent->IsElement() == true.
> 
> What does 0xc crash address point to here?

Good question. I don't know why 0xc is reported as the crashing address for all these reports.

(Note this is not a high volume crash)

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Still around. Seems the stacks are all similar and related to XULTabAccessible, like:

0 	xul.dll mozilla::a11y::FocusManager::IsFocused(mozilla::a11y::Accessible const*) 	accessible/src/base/FocusManager.cpp
1 	xul.dll 	mozilla::a11y::Accessible::NativeState() 	accessible/src/generic/Accessible.cpp
2 	xul.dll 	mozilla::a11y::XULTabAccessible::NativeState() 	accessible/src/xul/XULTabAccessible.cpp
3 	xul.dll 	mozilla::a11y::Accessible::State() 	accessible/src/generic/Accessible.cpp
4 	xul.dll 	mozilla::a11y::AccessibleWrap::get_accState(tagVARIANT, tagVARIANT*)

https://crash-stats.mozilla.com/report/index/f8f09027-bd88-4ed2-b08e-d4c662140911

Comment 4

[alexander :surkov (:asurkov)]

what's interesting, the code path is triggered by ffxtn.dll which is malicious application, it seems to be one more use case of a11y

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to alexander :surkov from comment #4)
> what's interesting, the code path is triggered by ffxtn.dll which is
> malicious application, it seems to be one more use case of a11y

Oh crap.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Benjamin, what is the right process here? Nominate ffxtn.dll for WindowsDllBlocklist.cpp?

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Oh I found https://wiki.mozilla.org/Blocklisting#How_to_request_a_block

Alex is this dll in all the stacks?

Comment 8

[Benjamin Smedberg]

You can morph this bug into a DLL block if you want. We probably need to make sure that we won't be blocking real things along with the unwanted thing. dmajor can help walk you through it and review patches.

Comment 9

[(Away)]

I'm not convinced that a block is worth spending time on. Across all products and channels we get something like 10 crashes a day. Our correlation files don't even include such crashes, so I had to spot-check by hand: about one third have ffxtn, another third have other malware, and the last third look like our fault. The Socorro folks might be able to run a more accurate query if you really want.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks for the manual checking David!

OK let's not morph this bug.

Comment 11

[alexander :surkov (:asurkov)]

the latest affected Firefox is 56, we should probably mark it wontfix.

Comment 12

[Wayne Mery (:wsmwk)]

Crash rate reduced significantly after version 52.
Both Firefox crashes I looked at have uiautomationcore.dll on stack

Also, none of the current crashes are Mac https://crash-stats.mozilla.org/signature/?version=%2152.9.0esr&version=%2152.8.0esr&signature=mozilla%3A%3Aa11y%3A%3AFocusManager%3A%3AIsFocused&date=%3E%3D2019-10-04T12%3A56%3A00.000Z&date=%3C2020-04-04T12%3A56%3A00.000Z#aggregations

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.