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>
Created attachment 254812 [details] patch
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 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
Maybe WebKit’s implementation of the animation is synchronous and the AppKit version is not?
(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 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.
(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 on attachment 254812 [details] patch Clearing flags on attachment: 254812 Committed r185573: <http://trac.webkit.org/changeset/185573>
All reviewed patches have been landed. Closing bug.