Bug 145933 - AX: Changing state of radio buttons causes VoiceOver to go busy for a short time.
Summary: AX: Changing state of radio buttons causes VoiceOver to go busy for a short t...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: chris fleizach
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-06-12 11:46 PDT by chris fleizach
Modified: 2015-06-29 02:53 PDT (History)
6 users (show)

See Also:


Attachments
patch (2.07 KB, patch)
2015-06-12 11:49 PDT, chris fleizach
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description chris fleizach 2015-06-12 11:46:17 PDT
If I use plain arrows to change between the three radio buttons on this page, VO goes busy after the third or fourth movement.

<rdar://problem/19801366>
Comment 1 chris fleizach 2015-06-12 11:49:10 PDT
Created attachment 254812 [details]
patch
Comment 2 Darin Adler 2015-06-15 11:00:55 PDT
Comment on attachment 254812 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=254812&action=review

> Source/WebCore/platform/mac/ThemeMac.mm:202
> +    // The animated state cause this thread to start and stop repeatedly on CoreAnimation synchronize calls.
> +    // This short burts of activity in between are not long enough for VoiceOver to retrieve accessibility attributes and makes the process appear unresponsive.
> +    if (AXObjectCache::accessibilityEnhancedUserInterfaceEnabled())
> +        useAnimation = false;

Is this the right thing to do? Does the rest of OS X turn off radio button animation when VoiceOver is on? Or is this rule specific to WebKit? Is there some way we can share the logic with the rest of the OS?
Comment 3 chris fleizach 2015-06-15 11:10:23 PDT
Comment on attachment 254812 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=254812&action=review

>> Source/WebCore/platform/mac/ThemeMac.mm:202
>> +        useAnimation = false;
> 
> Is this the right thing to do? Does the rest of OS X turn off radio button animation when VoiceOver is on? Or is this rule specific to WebKit? Is there some way we can share the logic with the rest of the OS?

it looks like this doesn't happen elsewhere in the system for focused controls when VoiceOver is on (although in general turning off animations when VoiceOver is on is done occasionally). 
more investigation will be required to figure out the difference, although I fear we'll run out of time without getting to the root cause, which may be a thread scheduling issue or something as deep
Comment 4 Darin Adler 2015-06-15 11:21:01 PDT
Maybe WebKit’s implementation of the animation is synchronous and the AppKit version is not?
Comment 5 chris fleizach 2015-06-15 11:39:30 PDT
(In reply to comment #4)
> Maybe WebKit’s implementation of the animation is synchronous and the AppKit
> version is not?

What I saw was that there was a lot of blocking on CGSynchronize(). So a little bit of work was done, then it would synchronize and hang the thread briefly. 

My guess is that in AppKit that is not hanging the thread but either the run loop continues spinning or it happens on a different thread
Comment 6 Dean Jackson 2015-06-15 13:42:41 PDT
Comment on attachment 254812 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=254812&action=review

>>> Source/WebCore/platform/mac/ThemeMac.mm:202
>>> +        useAnimation = false;
>> 
>> Is this the right thing to do? Does the rest of OS X turn off radio button animation when VoiceOver is on? Or is this rule specific to WebKit? Is there some way we can share the logic with the rest of the OS?
> 
> it looks like this doesn't happen elsewhere in the system for focused controls when VoiceOver is on (although in general turning off animations when VoiceOver is on is done occasionally). 
> more investigation will be required to figure out the difference, although I fear we'll run out of time without getting to the root cause, which may be a thread scheduling issue or something as deep

The difference between WebKit and the rest of the OS is that we call redraw manually lots of times, drawing with CG, until AppKit tells us the animation is done. Other parts of the system just run a CA animation.

I'm ok with turning the animation off for this particular case, if Chris can't find another solution.
Comment 7 Dean Jackson 2015-06-15 13:47:23 PDT
(In reply to comment #6)
> Comment on attachment 254812 [details]

> The difference between WebKit and the rest of the OS is that we call redraw
> manually lots of times, drawing with CG, until AppKit tells us the animation
> is done. Other parts of the system just run a CA animation.

Which explains why you were seeing the CG syncs. Unfortunately we can't use the system animation because it would force us to layerize content.
Comment 8 WebKit Commit Bot 2015-06-15 17:41:09 PDT
Comment on attachment 254812 [details]
patch

Clearing flags on attachment: 254812

Committed r185573: <http://trac.webkit.org/changeset/185573>
Comment 9 WebKit Commit Bot 2015-06-15 17:41:13 PDT
All reviewed patches have been landed.  Closing bug.