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

document.activeElement is undefined #179

Closed
ypconstante opened this issue Nov 1, 2022 · 3 comments
Closed

document.activeElement is undefined #179

ypconstante opened this issue Nov 1, 2022 · 3 comments

Comments

@ypconstante
Copy link

Hello, I'm trying to use linkedom in a project to do unit tests, but I'm having issues with document.activeElement

Example:

const html = `
  <!doctype html>
  <html lang="en">
    <head><title></title></head>
    <body>
      <input type="text" id="input" name="input">
    </body>
  </html>
`;

const { window } = parseHTML(html);

const document = window.document;
const input = document.querySelector("input");
input.focus();

const activeElement = document.activeElement;

With jsdom activeElement will be the input element, but with linkedom activeElement is undefined
@WebReflection
Copy link
Owner

This project is not a replacement for JSDOM, it’s a module which goal is performance and SSR where there’s no DOM at all.
activeElement requires some convoluted logic I’ve no interest in implementing:

  • there’s only one active element
  • an element or its container can be removed and logic must follow
  • focus and blur have no real meanings in here
  • … and so on

if anyone would like to file an extremely simplified PR that in no way affects main goal performance and logic I’ll be happy to consider that, but I won’t personally work on this.

@ypconstante
Copy link
Author

Just in case someone has the same issue, I was able to make my tests work by using addEventListener

On the test setup:

    const onFocusCallback = vi.fn(() => null)
    element.addEventListener("focus", onFocusCallback)

After doing the call that changes the focus

    expect(onFocusCallback).toHaveBeenCalled();

@WebReflection
Copy link
Owner

Thank you for the fallback hint, I rather have a collection of these use cases than make LinkeDOM another JSDOM ... all performance gain here are because LinkeDOM is not, and never planned to be, a 1:1 representation of the DOM.

JSDOM goal is to help testing on DOM-less environments W3C/WHATWG standards and due that goal is slow (tons of added logic behind) ... as much as JSDOM has been wrongly used to SSR, I don't want LinkeDOM to be wrongly used as W3C specs test environment, as I don't care about replacing the best library out there to do so.

If developers have issues with JSDOM slowness, imagine the whole industry use that tool to move forward anyway ... so please consider just simplifying your tests, or don't look for "as standard as JSDOM is" alternatives, 'cause I think there are none, and that's OK here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@WebReflection @ypconstante