Created attachment 8543669 [details] gecko-shadow-dom-positive-tabindex.html 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.
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
Component: Untriaged → DOM
Product: Firefox → Core
See Also: → bug 1117535
FWIW, William told me this is a spec issue.
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.
You need to log in before you can comment on or make changes to this bug.