User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Steps to reproduce: 1. Create a custom element with shadow root 2. In the shadow DOM, add the div with overflow: hidden 3. In that div, place 2 focusable elements (e.g. button and input) 4. Focus the input 5. Press Shift+Tab, to move focus back to button 6. Press Shift+Tab once again https://jsfiddle.net/webpadawan/raox4mtu/ Actual results: focus moves out of the shadow root Expected results: focus returns back to the input
UPD: corrected description: Expected results: focus moves out of the shadow root Actual results: focus returns back to the input
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
That's indeed a bit wild, I bet this is related to the extra anonymous box we have for overflow: hidden. Olli, let me know if you want me to look at it, from a quick look I assume the bug is around this code, right? https://searchfox.org/mozilla-central/rev/c0b26c40769a1e5607a1ae8be37fe64df64fc55e/dom/base/nsFocusManager.cpp#3353
If you have time, feel free to take a look.
Yup! I was right on which code was wrong :-)
There are lots of frames which create anonymous content (like scrollframes, which generate scrollbars) but for which this code was wrong. Use StyleChildrenIterator which has a defined order between NAC and flattened tree. I've verified this doesn't break tabbing through input type="date" with UA widget disabled, fwiw.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/5322e59f933e Use StyleChildrenIterator instead of custom frame tree walking code to handle NAC inside shadow dom. r=smaug
I was meant to document the custom code as a clean-up after bug 1507895 and this is done already 👍
You need to log in before you can comment on or make changes to this bug.