New issue
Advanced search Search tips

Issue 665121 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

SVG <use> element and elements in <defs> receive keyboard focus

Reported by rodneyr...@googlemail.com, Nov 14 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2919.0 Safari/537.36

Steps to reproduce the problem:
1. create an SVG with a <a> in <defs> and have a <use tabindex="-1"> reference that
2. press the Tab key 

see http://jsbin.com/wowububucu/edit?html,output

What is the expected behavior?
no element should receive focus

What went wrong?
* elements in <defs> receive focus, even though they're not rendered
* the <use> element receives focus, even though it has tabindex="-1"

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 56.0.2919.0  Channel: canary
OS Version: OS X 10.10.5
Flash Version: Shockwave Flash 24.0 r0

Only Blink and WebKit focus the <use> element if it references focusable content. Gecko, Trident and EdgeHTML always treat <use> inert, even if tabindex attribute is set.
 
svg-defs-use-focus.html
1.4 KB View Download

Comment 1 by dk...@chromium.org, Nov 14 2016

Cc: pdr@chromium.org aboxhall@chromium.org
+Philip from paint-dev (for SVG) and +Alice from accessibility (for focus)

Philip, Alice - do either of you know where this should be routed?

Comment 2 by dk...@chromium.org, Nov 14 2016

Status: Untriaged (was: Unconfirmed)
Seems to repro in Chrome 54.0.2840.71

Comment 3 by pdr@chromium.org, Nov 15 2016

Components: Blink>SVG
Labels: -OS-Mac OS-All
Status: Available (was: Untriaged)
Thanks for the reduced testcase. For setting priority, do you have a product or page that's affected by this?

Here's the spec:
https://svgwg.org/svg2-draft/single-page.html#interact-Focus
Elements receiving focus in <defs> is a clear bug spelled out in the spec. The <use> behavior isn't as obvious to me, but we should match other browsers.
> For setting priority, do you have a product or page that's affected by this?

nope. I run a bunch of tests to figure out how focus works across browsers. That's where I noticed the Chrome behavior.


> Elements receiving focus in <defs> is a clear bug spelled out in the spec. 

I probably shouldn't say that currently *every* rendering engine has the same bug.


Comment 5 by f...@opera.com, Nov 15 2016

I wonder if this could be the same as issue 506200 at the core. At least the "focus within <defs>". (I.e we have "non-rendered" elements that have LayoutObjects, so layoutObjectIsFocusable() will return true.)

As for the issue with <use>, I guess what happens there is that we try to focus the instance of the <a>, and then that bubbles out of the shadow tree - or something like that...
The <defs> issue is worse than expected. While the non-rendered element has focus, it is indicated in every <use> element referencing it. See http://jsbin.com/julekuxuwe/1/edit?html,output
Components: Blink>HTML>Focus
Components: -Blink>Focus
Project Member

Comment 9 by sheriffbot@chromium.org, Oct 1

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Available (was: Untriaged)

Sign in to add a comment