When html elements has transform style for example: transform: translateY(-50%); transform: translateX(-50%); VO’s black focus outline is drawn incorrectly. Instead of highlighting the exact text area, it will include extra space or shift. It’s reproducible on macOS and iOS 11 Reduction is attached
<rdar://problem/37547750>
Created attachment 369229 [details] Patch
Comment on attachment 369229 [details] Patch Attachment 369229 [details] did not pass mac-ews (mac): Output: https://webkit-queues.webkit.org/results/12119877 New failing tests: accessibility/form-control-value-settable.html
Created attachment 369237 [details] Archive of layout-test-results from ews100 for mac-highsierra The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews100 Port: mac-highsierra Platform: Mac OS X 10.13.6
Comment on attachment 369229 [details] Patch Attachment 369229 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/12119935 New failing tests: accessibility/form-control-value-settable.html
Created attachment 369240 [details] Archive of layout-test-results from ews105 for mac-highsierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-highsierra-wk2 Platform: Mac OS X 10.13.6
Comment on attachment 369229 [details] Patch Attachment 369229 [details] did not pass mac-debug-ews (mac): Output: https://webkit-queues.webkit.org/results/12120059 New failing tests: accessibility/form-control-value-settable.html
Created attachment 369242 [details] Archive of layout-test-results from ews115 for mac-highsierra The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews115 Port: mac-highsierra Platform: Mac OS X 10.13.6
Comment on attachment 369229 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=369229&action=review > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:839 > + else if (isWebArea() || isSVGRoot || isLink()) focus ring quads is what is used for drawing link highlights when you tab through the page through right? won't this give us the wrong bounding box?
This bug does not only make the focus rectangle appear in the wrong location, but can also cause any tap events to be sent to the wrong control. It seems to send the event to the control closest to the center of the focus rectangle, which may not be the one initially chosen (e.g., if signiicant scaling is applied).
ericliang@apple.com
I don't get it. Why are hyper links special? There are plenty of other elements that could be anchor-element-like.
Comment on attachment 369229 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=369229&action=review r- due to the lack of explaining & new tests. > Source/WebCore/ChangeLog:3 > + Size for accessibility links should not query hierarchy below the link because its ring should bound to itself. This line should match the bugzilla bug title. > Source/WebCore/ChangeLog:8 > + Tests updated Given that the original bug says this is about CSS transforms, we need new tests with CSS transforms, which demonstrates the issue at hand. > Source/WebCore/ChangeLog:9 > + Please explain how the bug was caused & how you're fixing it. > LayoutTests/ChangeLog:3 > + Size for accessibility links should not query hierarchy below the link because its ring should bound to itself. Ditto.
Ryosuke Niwa wrote: > Why are hyper links special? There are plenty of other elements... Yes, indeed, we're having this problem with "other elements". In our case, we have custom buttons made with DIVs (with role="button"), and they also exhibit BOTH the focus rectangle shown in the wrong place or size (the latter if scaling is applied) and also activating the wrong button when double-tapping the screen (the button at the center or mostly inside the focus rectangle is activated, which often is NOT the button originally selected by the user). -JM