When activating fragment URL that points to custom element with shadowDOM the sequential focus navigation starting point (https://html.spec.whatwg.org/multipage/browsing-the-web.html#scrolling-to-a-fragment:sequential-focus-navigation-starting-point) is set so that any focusable elements in custom element will be ignored. Everything seems to be by the spec when testing out simpler use-cases: https://codepen.io/hidde/pen/QvKGqa I created a more complex example that reproduces the bug: https://studio.webcomponents.dev/view/oH04HRauNorw5KhLGJH7 Although my target (#content) is custom element it should (to my understanding) not skip over the focusable elements inside custom elements shadowDOM. Latest chrome and firefox would not skip over the focusable elements inside shadowDOM.
<rdar://problem/111684394>
I'm having a trouble understanding what the reported bug is. What are exact steps to follow & what you're expecting to see vs. what you see instead?
Sorry for not explaining the steps to reproduce. Please follow the steps in this example: https://studio.webcomponents.dev/view/oH04HRauNorw5KhLGJH7 1. Click on the link "Content 2" 2. Press Tab to see keyboard focus 3. Focus shifts straight to green button that is inside #content-3 , skipping two green buttons inside #content-2 I would expect that after step 2 I would see the focus on the first green button inside #content-2. I refer to #content-2 and #content-3 as custom elements (regular-content) with their own shadow DOM. Following these steps in chrome/firefox would work as expected - focus in step 2 would shift to first green button inside the #content-2.
(In reply to Tanel Terras from comment #3) > Sorry for not explaining the steps to reproduce. > > Please follow the steps in this example: > https://studio.webcomponents.dev/view/oH04HRauNorw5KhLGJH7 > > 1. Click on the link "Content 2" > 2. Press Tab to see keyboard focus > 3. Focus shifts straight to green button that is inside #content-3 , > skipping two green buttons inside #content-2 > > I would expect that after step 2 I would see the focus on the first green > button inside #content-2. > > I refer to #content-2 and #content-3 as custom elements (regular-content) > with their own shadow DOM. > > Following these steps in chrome/firefox would work as expected - focus in > step 2 would shift to first green button inside the #content-2. Hm... as far as I've checked, Firfox and Safari behave the same and both moves the focus to the button inside #content-3. If wanted the behavior you're desiring, then yo should probably be setting "delegatesFocus" to true when creating the shadow root.
Created attachment 468230 [details] Chrome (Stable)
Created attachment 468231 [details] Safari 17
Sorry for the very delayed response. I have updated my example with delegatesFocus: true. It seems that this has no relation with the specific bug. I have attached the difference in browser implementations that can be observed when following the steps: 1. updated example: https://studio.webcomponents.dev/view/oH04HRauNorw5KhLGJH7?branch=delegatesFocus%40a7ImxJuv82MsKw89cF9BjqxK6XP2 2. Click on the link "Content 2" 3. Press Tab to see keyboard focus Safari seems to ignore the focusable elements inside my custom element shadowDOM when setting/updating the focus navigation starting point.