A negative tabindex on shadow host should be respected #399
Labels
Comments
|
Yeah, I think we can agree on this change. We should skip an entire shadow tree if the host has a negative tabindex. I guess @TakayoshiKochi already have this behavior in his proposal clearly, or not? That's actually what I wanted to change in v0, but it was too late to change. For v1, we should not do the same mistake. |
|
Makes sense that if a host is intentionally not focusable its descendants are not either. |
kisg
pushed a commit
to paul99/webkit-mips
that referenced
this issue
Mar 2, 2016
…tab focusable https://bugs.webkit.org/show_bug.cgi?id=154769 Reviewed by Antti Koivisto. Source/WebCore: Contents inside a shadow host with a negative tabindex content attribute should not be included in the sequential focus navigation order as discussed on WICG/webcomponents#399. Test: fast/shadow-dom/negative-tabindex-on-shadow-host.html * dom/Element.cpp: (WebCore::Element::tabIndexSetExplicitly): Added. * dom/Element.h: * page/FocusController.cpp: (WebCore::shadowAdjustedTabIndex): Renamed from adjustedTabIndex. Return 0 when tabindex content attribute is not explicitly set since element.tabIndex() would return -1 for HTML elements in such case. (WebCore::isFocusableOrHasShadowTreeWithoutCustomFocusLogic): Renamed from shouldVisit. (WebCore::FocusController::findElementWithExactTabIndex): (WebCore::nextElementWithGreaterTabIndex): (WebCore::previousElementWithLowerTabIndex): (WebCore::FocusController::nextFocusableElement): (WebCore::FocusController::previousFocusableElement): LayoutTests: Added a test for navigating across shadow boundaries. * fast/shadow-dom/negative-tabindex-on-shadow-host-expected.txt: Added. * fast/shadow-dom/negative-tabindex-on-shadow-host.html: Added. * platform/ios-simulator/TestExpectations: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@197439 268f45cc-cd09-0410-ab3c-d52691b4dbfc
|
Let me merge to #375. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related to the issue #375, both in the current specification and in the proposal in the issue #381, contents inside a shadow tree is treated as if its shadow host has the tabindex of 0.
However, when the shadow host has a negative tabindex, its contents should be not be in the sequential focus navigation order.
The
inputelement doesn't place focus in its editable region when it has a negative tabindex for example, and it's very counterintuitive for the tabindex on an element to be ignored just because it contains a focusable element.The text was updated successfully, but these errors were encountered: