Element.getAttributeNames() does not match browser behavior

[titouanmathis]

Describe the bug

The Element.getAttributeNames() in happy-dom v16 and v17 does not return the same values as browsers. It is working as expected in happy-dom v15.

To Reproduce

Try the following snippet in a browser console (tested in Firefox 135, Chrome 133 and Safari 18 on macOS):

const element = document.createElement('div');
element.setAttribute('ns1:key', 'value1');
element.setAttribute('ns2:key', 'value1');
element.setAttribute('key1', 'value1');
element.setAttribute('key2', '');

console.log(element.getAttributeNames());
// browser: ['ns1:key', 'ns2:key', 'key1', 'key2']
// happy-dom@17: ['ns2:key', 'key1', 'key2']

I also added a failing test in a fork: titouanmathis@8fba4af.

Expected behavior

happy-dom should return the same attributes as the browser when using the Element.getAttributeNames() method.

Screenshots
Not relevant.

Device:

• OS: macOS
• Browser: firefox
• Version: 135

Additional context

Bug encountered in a vitest environment.

[capricorn86]

Thank you for reporting @titouanmathis! 🙂

There is a fix in now.

[Jasonizl]

After updating to the 17.1.3 version, I now get this error when executing tests in a vite react application:
Failed to execute 'createAttributeNS' on 'Document': The namespace URI provided ('') is not valid for the qualified name provided ('xmlns:xlink').

It seems like the error is caused by svg files which follow the notation of xmlns="http://www.w3.org/2000/svg" xor even xmlnsXlink="http://www.w3.org/1999/xlink". Is this wanted or should I raise a new issue?

[denniseffing]

After updating to 17.1.3 we have issues with the selector getByTestId of @testing-library/dom. Tests now throw a TestingLibraryElementError with the message Unable to find an element by: [data-testid="toc-menu-content"], even though the element was rendered correctly (as shown by screen.debug()).

I haven't tried to reproduce it in a minimal sample yet.

EDIT: We now know that the issue is caused by cloning a node using cloneNode and then updating its data-testid via setAttribute. For some reason not only the cloned node is updated but the original node is updated as well. We presume that this behavior is somewhat related to the cache functionality, but we are not entirely sure. To be fair, cloning the node and updating its data-testid is pretty much a hack anyways but we don't have an alternative solution yet..