Closed
Bug 1117552
Opened 9 years ago
Closed 5 years ago
positive tabindex elements within ShadowDOM are improperly sorted into document's tabbing sequence
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: mail, Unassigned, NeedInfo)
References
Details
(Keywords: testcase)
Attachments
(1 file)
2.41 KB,
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141125180439 Steps to reproduce: 1. created a ShadowDOM structure (see attached test case) 2. add input elements with [tabindex=1] and [tabindex=0] to the document 3. add input elements with [tabindex=1] and [tabindex=0] to the ShadowRoot 4. hit <kbd>Tab</kbd> to see the tabbing sequence Live test case: http://medialize.github.io/ally.js/tests/browser-bugs/gecko-shadow-dom-positive-tabindex.html Actual results: The tabbing sequence showed that a shadowed element (i.e. an element within a ShadowRoot) with [tabindex=1] is tabbed to after the document's element with [tabindex=1] and before the document's element with [tabindex=0]. Also reproducible in Firefox Nightly 37.0a1 (2015-01-04). Expected results: the tabbing sequence should've been document[tabindex=1], document[tabindex=0], shadowed[tabindex=1], shadowed[tabindex=0] http://w3c.github.io/webcomponents/spec/shadow/#focus-navigation does not specify [tabindex=1] to be handled globally, rather considers the entire navigation order of the ShadowRoot to be a sub-sequence (as is) of the document's tabbing sequence.
Reporter | ||
Updated•9 years ago
|
Summary: positive tabindex elements within ShadowDOM are properly sorted into document's tabbing sequence → positive tabindex elements within ShadowDOM are improperly sorted into document's tabbing sequence
Updated•9 years ago
|
Updated•9 years ago
|
Flags: needinfo?(wchen)
Comment 1•9 years ago
|
||
FWIW, William told me this is a spec issue.
Comment 2•9 years ago
|
||
The current behavior in the spec doesn't handle distributed content. There is currently an open bug for that issue (https://github.com/w3c/webcomponents/issues/103) but it looks like latest resolution is that there really isn't a clear solution and it has been marked for shadow DOM v2 so I guess we'll implement the current behavior for now.
Comment 3•5 years ago
|
||
2019-03-06
This bug is part of a group of bugs which have had an open needinfo for at least 12 weeks.
The request for information has not been answered, and we can't move forward on the bug so we are closing it.
If the defect is still present, please reopen this bug with an updated report.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•