WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
Bug 159137
focus-within
Focused elems should loose focus on iOS tap outside of those boundaries
https://bugs.webkit.org/show_bug.cgi?id=159137
Summary
Focused elems should loose focus on iOS tap outside of those boundaries
hexalys
Reported
2016-06-27 02:33:17 PDT
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2016-06-27 09:54:41 PDT
<
rdar://problem/27030738
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug