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.

Sign up for GitHub

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

Jump to bottom

Autofocus doesn't work on sl-input in Firefox and Safari #2000

Open
WouldYouKindly opened this issue Apr 27, 2024 · 9 comments
Open

Autofocus doesn't work on sl-input in Firefox and Safari #2000

WouldYouKindly opened this issue Apr 27, 2024 · 9 comments
Assignees
@KonnorRogers
Labels
bug Things that aren't working right in the library. upstream An upstream issue is blocking the issue.

Comments

@WouldYouKindly
Copy link

Hi! Here's the reproducer:

<!DOCTYPE html>
<html lang="en" class="sl-theme-dark">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Slash code</title>

  <script type="module">
    import "@shoelace-style/shoelace";
    import '@shoelace-style/shoelace/dist/themes/dark.css';

    import {html, LitElement} from 'lit';

    class Debug extends LitElement {
        render() {
            return html`<sl-input autofocus></sl-input>`;
        }
    }

    customElements.define('debug-page', Debug);
  </script>
</head>

<body>
  <debug-page></debug-page>
</body>

</html>

When opened in Firefox or Safari, the input is not focused. It works as expected in Chrome.

On top of that, if I try to focus the input manually, I get another error:

firstUpdated() {
    this.shadowRoot.querySelector('sl-input').focus();
}

results in TypeError: this.input is null inside SlInput. This occurs on all three browsers.

Browser / OS

  • OS: Mac
  • Browser: Firefox 125.0.1 / Safari 17.2.1
@WouldYouKindly WouldYouKindly added the bug Things that aren't working right in the library. label Apr 27, 2024
@CetinSert
Copy link

CetinSert commented Apr 29, 2024 •
edited
Loading

Publicly reproduced using nothing but Shoelace from a CDN:

Confirmed as working ✔️ on Windows (Edge/Chrome 124); not working ❌ on Windows (Firefox 125), macOS (Safari 17.4)

@claviska claviska assigned claviska and KonnorRogers and unassigned claviska May 10, 2024
@claviska
Copy link
Member

@KonnorRogers do you mind looking into this one as part of the FACE work for Web Awesome?

@KonnorRogers
Copy link
Collaborator

KonnorRogers commented May 28, 2024 •
edited
Loading

@claviska I think this is an implementation issue. We could polyfill it, but perhaps we wait on the browsers to implement this? Chrome is the only one that behaves as expected.

It is still an issue with FACE, it doesnt seem to have changed behavior even with delegatesFocus: true

@claviska
Copy link
Member

Are there any relevant issues to link here for future reference? Any workarounds to suggest if we wait?

@KonnorRogers
Copy link
Collaborator

KonnorRogers commented Jun 3, 2024 •
edited
Loading

I can't find any issues about it.

It seems like people would need to do something like this:

<sl-input autofocus tabindex="0"></sl-input>

And then in our component, we could have a connectedCallback check that checks the current active element, and if <sl-input> is being currently focused and then adjust focus and removes the tabindex Note, without SSR, a user needs to add the tabindex because if we do it in the component, it fires too late.

Note, we can't use tabindex="-1" because it will make all children of the <sl-input> not focusable.

It's bizarre that it works as expected in chrome.

@claviska
Copy link
Member

claviska commented Jun 3, 2024

That feels weird. Should we open a browser bug about it before we hack something in the library?

@KonnorRogers
Copy link
Collaborator

That feels weird. Should we open a browser bug about it before we hack something in the library?

I'll open up browser bugs on Webkit and Firefox and see what they say.

@KonnorRogers
Copy link
Collaborator

Sooo on further investigation, Firefox + Safari do work. For Safari 17.4.1 it requires this.attachInternals(), for Firefox, it works simply with proper rendering.

Something about Lit's rendering seems to cause the issue.

Here's a minimal reproduction using a "vanilla" custom element.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title></title>
  </head>
  <body>
    <input>
    <my-input autofocus></my-input>

    <script type="module">
      import {LitElement, html} from 'https://cdn.jsdelivr.net/gh/lit/dist@3/core/lit-core.min.js';
      customElements.define("my-input", class extends LitElement {
        static formAssociated = true
        static shadowRootOptions = {...LitElement.shadowRootOptions, delegatesFocus: true }

        constructor () {
          super()
          this.internals = this.attachInternals()
        }

        render () {
          return html`<input>`
        }
      })

      // This works as expected.
      // customElements.define("my-input", class extends HTMLElement {
      //   static formAssociated = true
      //   constructor () {
      //     super()
      //     this.internals = this.attachInternals()
      //     this.attachShadow({ mode: "open", delegatesFocus: true })
      //   }

      //   connectedCallback () {
      //     this.shadowRoot.innerHTML = `<input>`
      //   }
      // })
    </script>
  </body>
</html>

Discord question: https://discord.com/channels/1012791295170859069/1247285261591904306/1247285261591904306

GitHub issue: lit/lit#4662

Browsers tested:

Chrome 125 ✅
Firefox 126.0.1 ❌
Safari 17.4.1 ❌

@KonnorRogers KonnorRogers added the upstream An upstream issue is blocking the issue. label Jun 3, 2024
@KonnorRogers
Copy link
Collaborator

KonnorRogers commented Jun 5, 2024 •
edited
Loading

So there's a few options here:

A.) We could "polyfill" autofocus by finding the first element in the DOM tree with the autofocus attribute, wait for it to be defined, and then focus it if its visible (autofocus shouldnt run for elements contained inside of popovers / dialogs)

B.) We could add a connectedCallback for autofocus, but could run into race conditions around when the elements is defined

C.) have users set a tabindex on the autofocusable element, when it "connects", remove the tabindex, and focus the appropriate first element in the shadow dom.

D.) Do nothing and just say its not well supported on first browser load to use autofocus and instead direct users to only use autofocus for dialogs / popovers and instead provide an "autofocus" script a user could run with client side JS to autofocus what they want by waiting for the element to be defined.

I'm personally leaning towards D since browsers seem to have some interesting timing issues around when the elements are defined and if theyll be autofocusable. , but happy to hear other thoughts

A user scripted version would look something like this:

window.addEventListener('DOMContentLoaded', () => {
  const el = document.querySelector('[autofocus]')

  if (el.tagName.includes("-")) {
    customElements.whenDefined(el.tagName.toLowerCase())
       .then(() => el.focus())
  } else {
    el.focus()
  }
})

@KonnorRogers KonnorRogers mentioned this issue Oct 16, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@KonnorRogers KonnorRogers

Labels
bug Things that aren't working right in the library. upstream An upstream issue is blocking the issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@CetinSert @claviska @WouldYouKindly @KonnorRogers