145933 2015-06-12 11:46:17 -0700 AX: Changing state of radio buttons causes VoiceOver to go busy for a short time. 2015-06-29 02:53:49 -0700 1 1 1 Unclassified WebKit Accessibility 528+ (Nightly build) All All RESOLVED FIXED InRadar P2 Normal --- 1 cfleizach cfleizach adam.g.helm commit-queue darin dino mario webkit-bug-importer oldest_to_newest 1101660 0 cfleizach 2015-06-12 11:46:17 -0700 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> 1101662 1 254812 cfleizach 2015-06-12 11:49:10 -0700 Created attachment 254812 patch 1101969 2 254812 darin 2015-06-15 11:00:55 -0700 Comment on attachment 254812 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? 1101975 3 254812 cfleizach 2015-06-15 11:10:23 -0700 Comment on attachment 254812 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 1101977 4 darin 2015-06-15 11:21:01 -0700 Maybe WebKit’s implementation of the animation is synchronous and the AppKit version is not? 1101981 5 cfleizach 2015-06-15 11:39:30 -0700 (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 1102026 6 254812 dino 2015-06-15 13:42:41 -0700 Comment on attachment 254812 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. 1102028 7 dino 2015-06-15 13:47:23 -0700 (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. 1102099 8 254812 commit-queue 2015-06-15 17:41:09 -0700 Comment on attachment 254812 patch Clearing flags on attachment: 254812 Committed r185573: <http://trac.webkit.org/changeset/185573> 1102100 9 commit-queue 2015-06-15 17:41:13 -0700 All reviewed patches have been landed. Closing bug. 254812 2015-06-12 11:49:10 -0700 2015-06-15 17:41:09 -0700 patch patch text/plain 2123 cfleizach SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDE4NTUxNykKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDIxIEBACisyMDE1LTA2LTEyICBDaHJpcyBG bGVpemFjaCAgPGNmbGVpemFjaEBhcHBsZS5jb20+CisKKyAgICAgICAgQVg6IENoYW5naW5nIHN0 YXRlIG9mIHJhZGlvIGJ1dHRvbnMgY2F1c2VzIFZvaWNlT3ZlciB0byBnbyBidXN5IGZvciBhIHNo b3J0IHRpbWUuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9p ZD0xNDU5MzMKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAg ICBXaGVuIHJhZGlvIGJ1dHRvbnMgYW5pbWF0ZSB0aGUgbmV3IGZvY3VzIHNlbGVjdGlvbiBzdGF0 ZSwgdGhlIHRocmVhZCBhY3Rpdml0eSBsb29rcyBhIGxvdCBsaWtlIHNob3J0IGJ1cnN0IG9mCisg ICAgICAgIGFjdGl2aXR5IHRvIGRyYXcsIHRoZW4gd2FpdCBvbiBDb3JlQW5pbWF0aW9uIHRvIGFw cGx5IHRob3NlIGNoYW5nZXMuCisKKyAgICAgICAgU2luY2UgdGhvc2UgcGVyaW9kcyBvZiBhY3Rp dml0eSBkdXJpbmcgYW5pbWF0aW9uIGFyZSBzbyBzaG9ydCwgVm9pY2VPdmVyIGlzIG5vdCBhYmxl IHRvIHF1ZXJ5IGZvciBhbGwgdGhlCisgICAgICAgIGF0dHJpYnV0ZXMgaXQgbmVlZHMsIGFuZCBn ZXRzIHN0dWNrIGluIHRoZSBxdWV1ZSBiZWhpbmQgcmVuZGVyaW5nLgorCisgICAgICAgIFRoZSBm aXggaGVyZSBpcyB0byB0dXJuIG9mZiBidXR0b24gc3RhdGUgYW5pbWF0aW9ucyB3aGlsZSBWb2lj ZU92ZXIgaXMgcnVubmluZy4KKworICAgICAgICAqIHBsYXRmb3JtL21hYy9UaGVtZU1hYy5tbToK KyAgICAgICAgKFdlYkNvcmU6OnVwZGF0ZVN0YXRlcyk6CisKIDIwMTUtMDYtMTIgIENvbW1pdCBR dWV1ZSAgPGNvbW1pdC1xdWV1ZUB3ZWJraXQub3JnPgogCiAgICAgICAgIFVucmV2aWV3ZWQsIHJv bGxpbmcgb3V0IHIxODU1MTIuCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9tYWMvVGhl bWVNYWMubW0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYkNvcmUvcGxhdGZvcm0vbWFjL1RoZW1l TWFjLm1tCShyZXZpc2lvbiAxODU0OTApCisrKyBTb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9tYWMv VGhlbWVNYWMubW0JKHdvcmtpbmcgY29weSkKQEAgLTI2LDYgKzI2LDcgQEAKICNpbXBvcnQgImNv bmZpZy5oIgogI2ltcG9ydCAiVGhlbWVNYWMuaCIKIAorI2ltcG9ydCAiQVhPYmplY3RDYWNoZS5o IgogI2ltcG9ydCAiQmxvY2tFeGNlcHRpb25zLmgiCiAjaW1wb3J0ICJHcmFwaGljc0NvbnRleHQu aCIKICNpbXBvcnQgIkxvY2FsQ3VycmVudEdyYXBoaWNzQ29udGV4dC5oIgpAQCAtMTk0LDYgKzE5 NSwxMiBAQAogI2lmIF9fTUFDX09TX1hfVkVSU0lPTl9NSU5fUkVRVUlSRUQgPCAxMDEwMDAKICAg ICBVTlVTRURfUEFSQU0odXNlQW5pbWF0aW9uKTsKICNlbmRpZgorCisgICAgLy8gVGhlIGFuaW1h dGVkIHN0YXRlIGNhdXNlIHRoaXMgdGhyZWFkIHRvIHN0YXJ0IGFuZCBzdG9wIHJlcGVhdGVkbHkg b24gQ29yZUFuaW1hdGlvbiBzeW5jaHJvbml6ZSBjYWxscy4KKyAgICAvLyBUaGlzIHNob3J0IGJ1 cnRzIG9mIGFjdGl2aXR5IGluIGJldHdlZW4gYXJlIG5vdCBsb25nIGVub3VnaCBmb3IgVm9pY2VP dmVyIHRvIHJldHJpZXZlIGFjY2Vzc2liaWxpdHkgYXR0cmlidXRlcyBhbmQgbWFrZXMgdGhlIHBy b2Nlc3MgYXBwZWFyIHVucmVzcG9uc2l2ZS4KKyAgICBpZiAoQVhPYmplY3RDYWNoZTo6YWNjZXNz aWJpbGl0eUVuaGFuY2VkVXNlckludGVyZmFjZUVuYWJsZWQoKSkKKyAgICAgICAgdXNlQW5pbWF0 aW9uID0gZmFsc2U7CisgICAgCiAgICAgQ29udHJvbFN0YXRlczo6U3RhdGVzIHN0YXRlcyA9IGNv bnRyb2xTdGF0ZXMtPnN0YXRlcygpOwogCiAgICAgLy8gSG92ZXIgc3RhdGUgaXMgbm90IHN1cHBv cnRlZCBieSBBcXVhLgo=