Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[scoped-custom-element-registry]: Safari v16.4 focuses all custom elements #546

Open
1 of 5 tasks
deepsweet opened this issue Jun 15, 2023 · 4 comments · May be fixed by #581
Open
1 of 5 tasks

[scoped-custom-element-registry]: Safari v16.4 focuses all custom elements #546

deepsweet opened this issue Jun 15, 2023 · 4 comments · May be fixed by #581

Comments

@deepsweet
Copy link

Description

Safari v16.4 supports attachInternals and formAssociated features natively, and with the subject polyfill enabled all custom elements on the page are keyboard-focusable using Tab key, regardless of the role or anything else.

Here is the root of the problem:

static get ['formAssociated']() {
return true;
}

Feels like Safari tries to focus any element with static formAssociated = true. If I change that to false in the polyfill source code then the above wrong behavior becomes fixed.

Is there a way to respect the original formAssociated value instead of enforcing it to be true?

Example

<!DOCTYPE html>
 <html>
 <head>
   <script src="https://www.unpkg.com/@webcomponents/scoped-custom-element-registry@0.0.9/scoped-custom-element-registry.min.js"></script>
 </head>
 <body>
   <input type="text"/>
   <my-el></my-el>
 
   <script>
     class MyEl extends HTMLElement {
       constructor() {
         super()
 
         const shadow = this.attachShadow({ mode: 'open' })
 
         shadow.innerHTML = '<span>Hello</span>'
       }
     }
 
     customElements.define('my-el', MyEl)
   </script>
 </body>
 </html>

Version

v0.0.9

Browsers affected

  • Chrome
  • Firefox
  • Edge
  • Safari
  • IE 11
@deepsweet
Copy link
Author

Is there a way to respect the original formAssociated value instead of enforcing it to be true?

Something like this:

static get ['formAssociated']() { 
-  return true;
+  return window.customElements._getDefinition(tagName)?.formAssociated ?? false
}

@michaelwarren1106
Copy link

im seeing this also. i wonder how we can tell safari not to allow host elements to be focusable when formAssociated is true?

@sorvell
Copy link
Collaborator

sorvell commented Dec 5, 2023

Can delegatesFocus: true be used to solve this? It seems like it. Is there any case where you wouldn't want to use that?

@michaelwarren1106
Copy link

I think this is kind of a mixing of issues? in Safari, all formAssociated elements are tabbable. That is kinda separate from what happens "when you tab" to an element imo. delegatesFocus only deals with what should happen when you tab to a custom element. Imo delegatesFocus isn't a solution for "my text component shouldn't be tabbable in the first place". The issue today is if I make a text component using the current polyfill, that element can receive keyboard focus in Safari when it shouldnt.

focus delegation is broken because it breaks text selection. If you have focus delegation turned on, then the act of focusing that internal focusable element breaks the selection event somehow. You click into an element to start selecting, the focus happens, and selection stops.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants