[Webkit-unassigned] [Bug 159137] New: [focus-within] Focused elems should loose focus on iOS tap outside of those boundaries

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=159137

            Bug ID: 159137
           Summary: [focus-within] Focused elems should loose focus on iOS
                    tap outside of those boundaries
    Classification: Unclassified
           Product: WebKit
           Version: Safari 9
          Hardware: iOS
               URL: http://www.hexanet.com/test/nav.htm
                OS: iOS 9.3
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: CSS
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: bruno at hexanet.net

The bugs report is the purpose of the :focus-within implementation with touch on iOS, as well as possible changes for the problematic "sticky" :hover touch behavior.

The current iOS safari behavior with :focus is currently buggy for :focus-within to work for the use cases it was intended for. A tap outside a focused element does no properly "unfocus" the previous element, and related panels, like other touch browsers do.

The attached is a reduced case of a navigation menu with dual toggle+link button and a toggle example. It uses the focus state primarily to:

1. Allow the dual link-toggle behavior (by canceling click on first taps).
2. Replicate/follow the Voice Over focus state behavior for styling.
3. A special touch is used to for fast-click and click cancels (pre 9.3)

If you tap the dual button+link or the toggle, it will focus the <a> element and bring the related-up menu.

What is expected: When a tap is made anywhere outside of the area. It should release both the :focus and :hover state from these elements. It doesn't. 
A button or a 'touchout' special event, or a focus layer underneath is the only way to release that state. I myself use a special 'touchout' event, using iOS detection and the 'touchout.mb' event left in the code. (The handler is left-out and not in this sample code to show the bug)

The issue is problematic for accessibility on VO. Say if you tap, or do a sequential read, on another non focusable element (e.g. the "States" text on the repro). It doesn't release the other focuses states. That can result in having what is highlighted from VO, as being hidden below a panel still open, for example. The navigation use case is one of the top examples for what :focus-within is aimed to resolve, with the ability for CSS only styling, and no, or at least less, reliance on Javascript for the behavior.

And while the sticky :hover behavior change isn't required for :focus-within in particular, that behavior has been a pain for many years, as reported numerous times on StackOverflow*, with silly hacks to go around the issue:

http://stackoverflow.com/questions/10642953/mobile-safari-links-retains-focus-after-touch
http://stackoverflow.com/questions/25993771/hover-effect-on-ipad-not-going-off
http://stackoverflow.com/questions/17233804/how-to-prevent-sticky-hover-effects-for-buttons-on-touch-devices
http://stackoverflow.com/questions/19713842/hover-state-doesnt-end-on-ios

Fixing both at once would be great.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160627/81dec421/attachment-0001.html>