Open kirstenxrauffer opened 1 month ago
Thanks for the issue. I was hoping that our work on ShadowDOM support would help this, unfortunately it appears not.
Instead, we might be able to use something like
|| e.target.tagName === 'VIDEO'
Though I'm worried that the focus will get stuck in a loop on the video element if it's the last element in the containing focus scope.
@snowystinger Your solution worked for me in a local sandbox of the code! Do you think it'd be okay for me to write a test for this and put a PR up for it? Is this something that would be okay to have as a long term fix?
Edit to add: I realized that to properly test this I'll have to add a dummy video to the test data. Would this be okay? Any recommendations such as file size limitations, where the dummy asset should be placed, etc?
Edit to add: Through more testing, this fix does have the side effect of causing an infinite focus loop on a video element so it is not a viable fix
We can probably just reference someone elses video https://www.w3schools.com/html/html5_video.asp for example, you can just use the URL of that sample video
It would be good to figure out why exactly it is still looping back to the video with the changes made in the PR. One possible idea that came up would be to specifically detect via a focus/blur listener when focus is entering/leaving the video element and control the focus marshalling in FocusScope around that specifically.
@LFDanLu @snowystinger I did try to add a focus listener to the video element to see what's happening with the looping bug, but interestingly, the controls other than the very first control do not trigger the focus change event listener. I don't know if I'll have time to do the blur listener but I do like that approach, that's essentially how I have seen other libraries like react-focus-lock
handling it. Just observing the focus and only refocusing on the next appropriate element when needed, like when the focus is about to leave the focus locking scope.
Provide a general summary of the issue here
When using a native HTML video element inside of
FocusScope
withcontains={true}
, we are unable to tab into the individual native video controls like fullscreen, volume, etc.π€ Expected Behavior?
Focus trapping an element should still allow for the native video controls to be accessible via keyboard using the tab key.
π― Current Behavior
If you place a native HTML video element inside of
FocusScope
like this pseudo-code:Then you are unable to tab into the individual video controls using a keyboard. The video element is in focus, but the focus never goes deeper.
π Possible Solution
No response
π¦ Context
This is a breaking scenario for keyboard-only users for native video elements inside of
FocusScope
.π₯οΈ Steps to Reproduce
FocusScope
like this pseudo-code:If I comment out
contain={ true }
forFocusScope
, I am able to access the video controls as expected, but of course the focus trapping does not work at that point.Version
3.17.1
What browsers are you seeing the problem on?
Firefox, Chrome, Safari
If other, please specify.
(I have not been able to test on Edge)
What operating system are you using?
Mac Sonoma 14.3.1
π§’ Your Company/Team
No response
π· Tracking Issue
No response