New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 770400 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug
Team-Accessibility



Sign in to add a comment

ClickHoldButtonCell causing accessibility exception throw

Project Member Reported by shrike@chromium.org, Sep 29 2017

Issue description

Chrome Version: 61.0.3163.100
OS: 10.12

The crash crash/7280a1ddd8ef2dfb shows the following exception being thrown (not saying it's the cause of the crash):

NSAccessibilityException reason "AXChildren" attribute unsupported by: <ClickHoldButtonCell: 0x7fdf80573be0>

-> ellyjones@ for triage and assignment

 
Labels: -Pri-3 Pri-2
Owner: spqc...@chromium.org
I think that exception happens "normally" and is eaten by AppKit, but we end up logging it anyway.

This crash is a zombie call, caused by something in the touchbar code. The zombie call is:

0x0000000104426fde	(Google Chrome Framework -objc_zombie.mm:237 )	(anonymous namespace)::ZombieObjectCrash(objc_object*, objc_selector*, objc_selector*)
0x0000000104427011	(Google Chrome Framework -objc_zombie.mm:280 )	-[CrZombie respondsToSelector:]
0x00007fff8ea24ff0	(AppKit + 0x00a1bff0 )	-[NSTextInputContext candidateListTouchBarItem]
0x00007fff8e21b92b	(AppKit + 0x0021292b )	-[NSTextInputContext deactivate]
0x00007fff8ea24e86	(AppKit + 0x00a1be86 )	+[NSTextInputContext currentInputContext_withFirstResponderSync:]
0x00007fff8e194be1	(AppKit + 0x0018bbe1 )	+[_NSAutomaticFocusRing setActiveFirstResponderChanged]
0x00007fff8e194b48	(AppKit + 0x0018bb48 )	___NSPostActiveFirstResponderChanged_block_invoke
0x00007fff90575d36	(CoreFoundation + 0x000a6d36 )	__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
0x00007fff90575ca6	(CoreFoundation + 0x000a6ca6 )	__CFRunLoopDoObservers
0x00007fff905566d8	(CoreFoundation + 0x000876d8 )	__CFRunLoopRun
0x00007fff90556113	(CoreFoundation + 0x00087113 )	CFRunLoopRunSpecific
0x00007fff8fab6ebb	(HIToolbox + 0x00030ebb )	RunCurrentEventLoopInMode
0x00007fff8fab6cf0	(HIToolbox + 0x00030cf0 )	ReceiveNextEventCommon
0x00007fff8fab6b25	(HIToolbox + 0x00030b25 )	_BlockUntilNextEventMatchingListInModeWithFilter
0x00007fff8e04fa53	(AppKit + 0x00046a53 )	_DPSNextEvent
0x00007fff8e7cb7ed	(AppKit + 0x007c27ed )	-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
0x0000000103451e9f	(Google Chrome Framework -chrome_browser_application_mac.mm:187 )	__71-[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:]_block_invoke
0x000000010385bc29	(Google Chrome Framework + 0x01ab4c29 )	base::mac::CallWithEHFrame(void () block_pointer)
0x0000000103451de3	(Google Chrome Framework -chrome_browser_application_mac.mm:186 )	-[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
0x00007fff8e0443da	(AppKit + 0x0003b3da )	-[NSApplication run]
0x000000010386c2ad	(Google Chrome Framework -message_pump_mac.mm:749 )	base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*)
0x000000010386acab	(Google Chrome Framework -message_pump_mac.mm:141 )	base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)
0x000000010388db52	(Google Chrome Framework -run_loop.cc:111 )	base::RunLoop::Run()
0x0000000103457d45	(Google Chrome Framework -chrome_browser_main.cc:1967 )	ChromeBrowserMainParts::MainMessageLoopRun(int*)
0x0000000102392e13	(Google Chrome Framework -browser_main_loop.cc:1169 )	content::BrowserMainLoop::RunMainMessageLoopParts()
0x00000001023954d1	(Google Chrome Framework -browser_main_runner.cc:142 )	content::BrowserMainRunnerImpl::Run()
0x000000010238ee9b	(Google Chrome Framework -browser_main.cc:46 )	content::BrowserMain(content::MainFunctionParams const&)
0x000000010340e5cf	(Google Chrome Framework -content_main_runner.cc:686 )	content::ContentMainRunnerImpl::Run()
0x0000000104d31be3	(Google Chrome Framework -main.cc:469 )	service_manager::Main(service_manager::MainParams const&)
0x000000010340dbb3	(Google Chrome Framework -content_main.cc:19 )	content::ContentMain(content::ContentMainParams const&)
0x0000000101daacb7	(Google Chrome Framework -chrome_main.cc:139 )	ChromeMain
0x0000000101d2ddd3	(Google Chrome -chrome_exe_main_mac.cc:170 )	main
0x00007fffa5cde234	(libdyld.dylib + 0x00005234 )	start

and the dealloc is:

0x02680547 [Google Chrome Framework -	 objc_zombie.mm:141] (anonymous namespace)::ZombieDealloc(objc_object*, objc_selector*)
0x0003a65b [AppKit +	 0x3a65b] -[NSResponder dealloc]
0x00039072 [AppKit +	 0x39072] -[NSView dealloc]
0x0260d378 [Google Chrome Framework -	 base_view.mm:32] -[BaseView dealloc]
0x008c14b8 [Google Chrome Framework -	 render_widget_host_view_mac.mm:1800] -[RenderWidgetHostViewCocoa dealloc]
0x0000f2e7 [libobjc.A.dylib +	 0xf2e7] objc_object::sidetable_release(bool)
0x0017b55e [CoreFoundation +	 0x17b55e] common_removeAllObjects
0x0002d913 [CoreFoundation +	 0x2d913] -[__NSArrayM dealloc]
0x0000f2e7 [libobjc.A.dylib +	 0xf2e7] objc_object::sidetable_release(bool)
0x0009b773 [CoreFoundation +	 0x9b773] -[__NSOrderedSetM dealloc]
0x0000f2e7 [libobjc.A.dylib +	 0xf2e7] objc_object::sidetable_release(bool)
0x006eee6f [AppKit +	 0x6eee6f] -[NSTouchBarFinder _update]
0x006ef28e [AppKit +	 0x6ef28e] __36-[NSTouchBarFinder __setNeedsUpdate]_block_invoke
0x000a6d37 [CoreFoundation +	 0xa6d37] __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
0x000a6ca7 [CoreFoundation +	 0xa6ca7] __CFRunLoopDoObservers
0x00087136 [CoreFoundation +	 0x87136] CFRunLoopRunSpecific
0x00030ebc [HIToolbox +	 0x30ebc] RunCurrentEventLoopInMode

the appearance of the touch bar in both stacks is suspicious to me.

spqchan@, any ideas?
Cc: spqc...@chromium.org
Owner: ellyjo...@chromium.org
We're tracking this particular crash in a different bug ( issue 684388 ). I filed this one to get the exception fixed (the exception and crash are not necessarily related).

> I think that exception happens "normally" and is eaten by AppKit, but we end up logging it anyway.

As far as I can tell ClickHoldButtonCell is code we own, so this seems like a bug we should fix for correctness?

Labels: -Pri-2 Pri-3
Hm, I'm not sure what to make of this exception. When testing locally, ClickHoldButtonCell *does* support AXChildren, via inheritance from NSButtonCell, which implements it. NSButtonCell returns nil for AXChildren instead of the expected @[], which is surprising. If the reports of this were from 10.9, I'd be prepared to blame the OS version, but the linked report is from 10.12.6.

I don't really understand what's going on here. I can't see any concrete negative consequences of this exception being thrown & caught inside AppKit, except that it's probably pretty slow and overwrites the "last exception" field inside our crash reports. We could add a value for NSAccessibilityChildrenAttribute in -[ClickHoldButtonCell accessibilityAttributeValue:], but since there already is one on NSButtonCell, I'm puzzled by this exception being thrown, and not confident that such a change would fix it.

I'm going to drop this to Pri-3 in the absence of either a path forward or a user impact.
<https://chromium-review.googlesource.com/c/chromium/src/+/716456> is what a fix for this would look like perhaps.
Status: WontFix (was: Assigned)
Triaging: it's not likely I will make time to fix this while ClickHoldButtonCell is still in existence.

Sign in to add a comment