You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 19, 2024. It is now read-only.
The iron-overlay-element by default sets focus to any child of itself which has the "autofocus" attribute. However, it does not do so for descendants which are within another custom element.
Every time the overlay opens, the autofocus input element gets focus.
Actual outcome
The autofocus input element only gets focus the first time the overlay opens (due to native browser support for autofocus, not due to actions taken by iron-overlay-behavior). The element does not get focus subsequent times.
This causes the querySelector to crawl all descendents of the element, even those within the shadow dom of a child element, rather than only considering the custom elements themselves. However, I suspect that Polymer.dom(this) is used for a reason and this may not be the desired approach, so I haven't directly submitted a pull request.
The text was updated successfully, but these errors were encountered:
Hi @aarongable, the suggested change will not work with native ShadowDOM, as this.querySelector will have visibility only on the light dom of the overlay (in your case, <gr-overlay> will see only <cr-tryjob-picker>).
You'll need to set autofocus on <cr-tryjob-picker>, make it focusable but not tabbable (set tabindex=-1), and handle focus redirection to the <input> in the shadowRoot.
I still think it would be useful for iron-overlay-behavior to be able to autofocus an element that is in the shadow dom of one of its descendants, especially for cases where the devloper is composing a lot of pre-made elements and wants to focus an input contained in (e.g.) a pre-made mailing address form element.
I believe iron-overlay-behavior should not pierce into children's shadowRoots, but just handle the light dom. A shadowRoot might be closed, hence iron-overlay-behavior wouldn't even be able to pierce those shadowRoots.
Declaring a shadowRoot with delegatesFocus: true addresses this issue; a custom element that delegates focus forwards the focus to its focusable content by default, and if no content is present, it keeps the focus on itself - see this explainer for more info.
This behavior is not polyfilled tho, and I believe it's currently implemented only on Chrome...
In Polymer, you can pass configuration options to attachShadow by overriding _attachDom method, see Polymer/polymer#3988 (comment)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
The iron-overlay-element by default sets focus to any child of itself which has the "autofocus" attribute. However, it does not do so for descendants which are within another custom element.
Steps to reproduce
Expected outcome
Every time the overlay opens, the autofocus input element gets focus.
Actual outcome
The autofocus input element only gets focus the first time the overlay opens (due to native browser support for autofocus, not due to actions taken by iron-overlay-behavior). The element does not get focus subsequent times.
Live demo
https://crrev.com/c/868827; sign in and then click "Choose Tryjobs"
Suggested action
The following patch is a working fix:
This causes the querySelector to crawl all descendents of the element, even those within the shadow dom of a child element, rather than only considering the custom elements themselves. However, I suspect that Polymer.dom(this) is used for a reason and this may not be the desired approach, so I haven't directly submitted a pull request.
The text was updated successfully, but these errors were encountered: