TypeError: activeElement.detachEvent is not a function

[hornta]

Works in jsdom
https://stackblitz.com/edit/vitest-dev-vitest-ktnq7h?file=test%2Fhappy-dom.test.tsx&initialPath=__vitest__

[frankandrobot]

Seeing this as well... somehow related to ant design components. Do you mind placing some more details here @hornta ?

[soker90]

Same error with happy-dom + testing-library:

import { it } from 'vitest'
import { render } from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import MyComponent from './MyComponent'

const user = userEvent.setup()

it('my test', async () => {
  const { getByPlaceholderText } = render(<MyComponent />)
  const input = getByPlaceholderText('any')

  await user.type(input, 'hello') // Crashs here
})

// vite.config.ts

/// <reference types="vitest" />
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  test: {
    globals: true,
    environment: 'happy-dom',
    coverage: {
      reporter: ['json', 'html'],
      exclude: [
        'node_modules/'
      ]
    }
  }
})

[hornta]

Seeing this as well... somehow related to ant design components. Do you mind placing some more details here @hornta ?

I don't know anything about ant design components. I think the bug triggers on different types of code in each code base so it's not trivial figuring out why it occurs but I posted a failing test in the link.

[doytch]

Yeah I'm running into this as well in a Remix/Vitest/RTL setup. blur events on a textfield seems to be what triggers it for me - whether that's via a simulated tab, clicking off, or manually firing a blur.

[cloud-walker]

Hi guys, any workaround on this?

[doytch]

Hi guys, any workaround on this?

Depends what you consider a workaround… We swapped our Vitest unit tests over to ole jsdom with zero friction.

[frankandrobot]

LoL. Note that tests don't run faster in vitest. The speedup is because test boot up is wayyyyyy faster, like 3x faster. But tests themselves will run at the same speed So in our particular case, we're seeing massively slow RTL tests (+30s runs) and happy-dom will let us scale... In addition to vitest On Jul 28, 2022 11:03 AM, Mark Deutsch ***@***.***> wrote: Hi guys, any workaround on this? Depends what you consider a workaround… We swapped our Vitest unit tests over to ole jsdom with zero friction. — Reply to this email directly, view it on GitHub<#534 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAGAGMLBLOYYAWNNZREVFPDVWKVOXANCNFSM53CL4B2A>. You are receiving this because you commented.Message ID: ***@***.***>

[cloud-walker]

I'm currently trying using jsdom selectively on affected test files

[aaronmccall]

Further info:

It looks like react-dom is considering happy-dom to be an IE9 environment due to feature detection, which is why it is trying to call detachEvent.

The detection appears to be due to both document and div element not supporting oninput attribute to set an input handler.

@capricorn86, does happy-dom not support on${eventName} attributes?

[aaronmccall]

Follow-up to my previous:

I can confirm that adding the following to EventTarget eliminates the error (though there is still the implementation issue that is causing react-dom to consider happy-dom to be IE9):

        /**
	 * Removes an event listener.
	 *
	 * This is only supported by IE8- and Opera, but for some reason React uses it and calls it, so therefore we will keep support for it until they stop using it.
	 *
	 * @param type Event type.
	 * @param listener Listener.
	 */
	public detachEvent(type: string, listener: ((event: Event) => void) | IEventListener): void {
		this.removeEventListener(type.replace('on', ''), listener);
	}

[frankandrobot]

@aaronmccall we are hitting this issue again. Is there a way to apply this workaround to the test config? (Note: your CR may or may not land since it doesn't address the underlying issue but in the mean time, we need to be unblocked :-) )

[aaronmccall]

@aaronmccall we are hitting this issue again. Is there a way to apply this workaround to the test config? (Note: your CR may or may not land since it doesn't address the underlying issue but in the mean time, we need to be unblocked :-) )

@frankandrobot I'm not sure. I'll let you know when I take a look next. (I'm not actually depending on happy-dom in my project yet.)

[nukeop]

I'm seeing this in vitest now, in a test that types text into an input.

[ilteoood]

@frankandrobot
To make it work, in the setupTests file, I've added the following line:

global.HTMLElement.prototype.detachEvent = function(type, listener) {
  this.removeEventListener(type.replace('on', ''), listener)
}

[capricorn86]

Hello everybody! 👋

Sorry that it took such a long time for me to look into this issue. It seems like a problem that probably affects many users. It has been a lot going on in my private and work life.

I have created a fix that fixes the root cause of the problem, which is that React believes that Happy DOM is a legacy browser. React could not find all the "on{event}" properties in the Document, which is something @aaronmccall discovered and mentioned in his pull request. Without him indicating where the problem was, I would not have been able to fix it this quickly.

You can read more about the release here:
https://github.com/capricorn86/happy-dom/releases/tag/v7.4.0