Comments (5)
One solution could be to just add 'iframe' to the candidateSelectors, but perhaps there is some issues with that?
I think the issue with that is that you do not in fact tab to the iframe
elements: you can tab to elements inside the iframe
.
We might have to document this as a caveat and leave it at that βΒ unless there's some clever way to reliably make this work. My understanding is that the JS in the parent document is typically not allowed to access the DOM of the iframe, unless they share the same domain. If they do share the same domain, iframe.contentWindow
could be used.
I don't plan to work on this myself but am open to PRs, if there's a simple approach to this.
from tabbable.
Yes, the issue is to tab into elements inside the iframe. I am actually using another one of your projects, namely react-aria-modal, and when I use an iframe component inside a dialog, I never get to tab into the iframe (e.g. to check a checkbox). But if I add 'iframe' to the candidateSelectors in tabbable, I'm allowed to tab into the elements in the iframe.
from tabbable.
But if I add 'iframe' to the candidateSelectors in tabbable, I'm allowed to tab into the elements in the iframe.
That's interesting ... I wonder what's going on there?
react-aria-modal uses focus-trap to trap focus inside the modal, and focus trap uses this library, tabbable, behind the scenes. I think this issue is similar to focus-trap/focus-trap#39, because elements with shadow DOM seem to have the same problem as iframes: tabbable doesn't recognize that they can contain tabbable elements, so focus-trap skips over them.
One possibility would be to change the way focus-trap controls tabbing. Right now, it hijacks the Tab key and manually chooses the next element to receive focus:
https://github.com/davidtheclark/focus-trap/blob/ef4da4f7b43f42d33487bcffb7deefd434a9ff50/index.js#L206-L226
We could change that so it only hijacks Tab if the focus change would end up leaving the focus trap. This should allow users within focus-traps to tab into an iframe or shadow DOM as long as there's a regular tabbable element on either side of it. That caveat is a weird one, though. I'm not sure it's reasonable to build in such a weird caveat.
So ... I don't know what to do! Open to solutions.
from tabbable.
Regarding Shadow DOM, collecting the list of tabbables is doable (e.g. see https://github.com/PolymerElements/iron-overlay-behavior/blob/master/iron-focusables-helper.html), but the hard part is keeping the correct order, as in Shadow DOM v1 tab order is affected by the order of distribution.
E.g. the correct ordering of tabbable nodes in this example is [#inputA, #inputB]. Even if #inputB has tabindex = 1, it is distributed in #slotB which comes after #slotA.
<my-element>
#shadowRoot
<slot id="slotA" name="a">
<slot id="slotB" name="b">
/#shadowRoot
<input id="inputA" slot="a">
<input id="inputB" slot="b" tabindex="1">
</my-element>
from tabbable.
I added some notes in the readme about this situation. If anyone knows how to improve it reliably and would like to submit a PR, please do!
from tabbable.
Related Issues (20)
- element.matches not working in ie 11. HOT 5
- Scroll containers HOT 3
- isTabbableRadio doesn't properly escape query selectors HOT 4
- Use @testing-library/dom and Jest for tests HOT 3
- Add code coverage badge to the README HOT 5
- Restore actual browser testing with Cypress HOT 8
- support inert attribute HOT 13
- Exclude form elements in `:disabled` fieldset HOT 2
- Optimizing displayCheck: 'full' HOT 9
- Bug: isDisabledFromFieldset doesn't check the top-most disabled <fieldset> HOT 3
- Safari: Object passed in getCheckedRadio is not iterable, causing a for loop error HOT 2
- v5.3.0 breaks literally all of our usage of `tabbable` π when called on a node not attached to the document HOT 40
- [MAJOR] isHidden should exclude detached nodes by default
- Firefox throws an error when checking disabled on non button element HOT 4
- IE support broken in v5.3.2+ HOT 1
- tabbable breaks when processing an element with a "scope" attribute HOT 6
- jest error Your focus-trap must have at least one container with at least one tabbable node in it at all times HOT 2
- Can't make it work testing with tabbable mocked HOT 7
- jsdom issue: 'slot):not([inert]' is not a valid selector HOT 7
- Remove nwsapi v2.2.2 override once bug is fixed
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tabbable.