@click.prevent not setting event.defaultPrevented in jest tests

[aethr]

Version

3.0.0

Reproduction link

https://github.com/aethr/vue-prevent-test

Steps to reproduce

Create a link with an a tag with a @click.prevent='clickHandler' event handler like:

  methods: {
    clickHandler(event) {
      console.log('event.defaultPrevented', event.defaultPrevented)
    }
  },

Click the link in the browser, console will show:

event.defaultPrevented true

Create a jest test that will trigger a click on the link like:

  it('does not try to follow a link', async () => {
    const wrapper = shallowMount(HelloWorld);
    wrapper.get('#link').trigger('click')
  })

Run jest test that trigger a click on the same element with npm run test:unit, console will show:

  console.log src/components/HelloWorld.vue:6
    event.defaultPrevented false

What is expected?

Using vue-test-utils to trigger a click event on a link should result in the same behaviour as we see in the browser, with event.defaultPrevented set properly.

What is actually happening?

Although the prevent modifier handler is being called, somehow the event itself is not being modified so that defaultPrevented is true.

---

My test case also includes an example of a basic jest test that sets up a similar example using pure jsdom, and we can see the correct event.defaultPrevented value is set, so I don't think this is an issue with jsdom.

In the app where we first saw this behaviour, we're seeing an error during one of our tests where jsdom thinks navigation is being attempted because an element with @click.prevent is causing navigation (but only in jsdom, not in the browser). We think it is probably related to this bug.

[posva]

@aethr transferred to the tests repository although this could be a problem on an upstream repo

[aethr]

Thanks, I just updated the test repo to add another link with event.preventDefault() called manually:

  <a id="link2" @click="clickPreventManual">Click</a>

    clickPreventManual(event) {
      event.preventDefault();
      console.log('event.defaultPrevented', event.defaultPrevented)
    }

This is also showing the same incorrect result:

  console.log src/components/HelloWorld.vue:10
    event.defaultPrevented false

So this isn't a bug with the prevent modifier, it seems to affect any event handler bound in vue template.

[lmiller1990]

I looked into this. It is an issue in Vue core, I could reproduce without VTU and with an SFC. I wonder why this only happens in the jsdom environment. Here is an more minimal repo, removing the SFC dependency.

To run this you need to do yarn add jsdom-global then just run node index.js.

require('jsdom-global')()
const { h, createApp } = require('vue')

const App = {
  name: 'A',
  render() {
    return h('div', [
      h('a', {
        onClick: event => { 
          event.preventDefault()
          console.log('event.defaultPrevented', event.defaultPrevented) // false
        }
      })
    ])
  }
}

const el = document.createElement('div')
const app = createApp(App).mount(el)
const evt = document.createEvent('Event')
evt.initEvent('click')
/**
 * This logs "event.defaultPrevented: false"
 */
el.querySelector('a').dispatchEvent(evt)

document.body.innerHTML = `
<div>
  <a id="no-href">Label</a>
</div>
`

const link = document.getElementById('no-href')

link.addEventListener('click', (event) => {
  event.preventDefault()
  console.log('event.defaultPrevented', event.defaultPrevented) // true
})

/**
 * This logs "event.defaultPrevented: true"
 */
link.click()

[lmiller1990]

@posva can you please transfer this issue to vue-core (I do not have access to do that).

[posva]

I tried without Vue and the problem is the same but the behavior is consistent with browsers: https://jsfiddle.net/tsmfyq1b/

Same in jsdom

const { JSDOM } = require("jsdom");

const dom = new JSDOM(`
<div>
  <a id="no-href">Label</a>
</div>
`);

const { document } = dom.window

const a = document.getElementById('no-href')
a.addEventListener('click', (event) => {
  event.preventDefault()
  console.log('event.defaultPrevented', event.defaultPrevented)
})
const evt = document.createEvent('Event')
evt.initEvent('click')
/**
 * This logs "event.defaultPrevented: false"
 */
a.dispatchEvent(evt)

/**
 * This logs "event.defaultPrevented: true"
 */
a.click()

So I think click might be a special case and should not be triggered using dispatchEvent

[lmiller1990]

Is there another way to click something without dispatching an event? There is HTMLElement.click but I think this is just doing the same thing. What do you mean but click is a special case (compared to other events? why?)

Is there actually a bug here? Also, are you trying to test @aethr? There is some basic info on testing routing in the docs.

[posva]

Nevermnid the statement about click.
It's worth checking in the spec if this is intended for events creating programmatically. BTW initEvent is deprecated, shouldn't you use new Event(eventName, { cancelable: true }) so defaultPrevented is set to true? https://jsfiddle.net/jzLepm49/

[aethr]

@lmiller1990 this was discovered as part of migrating our project from Vue 2 to Vue 3. Our app uses an <a @click="logout"> link which never caused any issues in Vue 2. After migrating to Vue 3 we started seeing console errors from jsdom during tests, and narrowed it down to the test that "clicks" the logout link and checks if a Vuex action has occurred. The errors we see are:

  ● Console

    console.error node_modules/jest-environment-jsdom-fifteen/node_modules/jsdom/lib/jsdom/virtual-console.js:29
      Error: Not implemented: navigation (except hash changes)
          at module.exports (/home/runner/work/geppetto-sender-ui/geppetto-sender-ui/node_modules/jest-environment-jsdom-fifteen/node_modules/jsdom/lib/jsdom/browser/not-implemented.js:9:17)
          at navigateFetch (/home/runner/work/geppetto-sender-ui/geppetto-sender-ui/node_modules/jest-environment-jsdom-fifteen/node_modules/jsdom/lib/jsdom/living/window/navigation.js:77:3)
          at exports.navigate (/home/runner/work/geppetto-sender-ui/geppetto-sender-ui/node_modules/jest-environment-jsdom-fifteen/node_modules/jsdom/lib/jsdom/living/window/navigation.js:55:3)
          at Timeout._onTimeout (/home/runner/work/geppetto-sender-ui/geppetto-sender-ui/node_modules/jest-environment-jsdom-fifteen/node_modules/jsdom/lib/jsdom/living/nodes/HTMLHyperlinkElementUtils-impl.js:81:7)
          at listOnTimeout (internal/timers.js:549:17)
          at processTimers (internal/timers.js:492:7) undefined

It seems that the error occurs because jsdom tries to "activate" the link element, causing navigation (which jsdom doesn't implement understandably). I haven't done a full deep dive on the jsdom code but this does seem to be because preventDefault isn't working correctly in that environment, only for "clicks" generated in our jest tests.

It's not a high priority fix for us, we can easily work around it (and probably shouldn't be using an <a> tag in that particular case). I just thought I'd report it here because it does seem like it might be a bug.

[lmiller1990]

Sure, thanks fore the great bug report! @posva looks like we are using new Event, see here. I wonder what happens if we do trigger('click', { cancellable: true }) in the reproduction repository.

I would really like to minimize breaking changes, so I can play around with this a little more. Let me know if either of you have any other ideas, too.

[aethr]

Great insight @lmiller1990 , I had a look at the implementation you linked and sure enough, it looks as though cancelable is not being added properly to the properties being returned by getEventProperties.

https://github.com/vuejs/vue-test-utils-next/blob/master/src/createDomEvent.ts#L115

I wonder if this is just a typo, as when I updated the source in my local deps to:

 const eventProperties = {
    ...systemModifiersMeta, // shiftKey, metaKey etc
    ...options, // What the user passed in as the second argument to #trigger
    bubbles: meta.bubbles,
    cancelable: meta.cancelable, // this was 'meta: meta.cancelable' before
    // etc

This seems to fix the issue, the test cases in the repo that were previously false now look like:

  console.log src/components/HelloWorld.vue:6
    event.defaultPrevented true

  console.log src/components/HelloWorld.vue:10
    event.defaultPrevented true

  console.log tests/unit/example.spec.js:27
    event.defaultPrevented true

[aethr]

I've put the 1 line change in a PR, apologies if this isn't desired!

[lmiller1990]

Awesome, thanks for the PR!! Why apologize when you are the one doing the work to fix a bug? 😛

I can review this within 48h and give it a quick test (I run the all the PRs against some personal code-bases to see if anything breaks). I usually release a new version at the end of each week.

I will give you a review and ping you if I notice anything, but at face value I see no problem 👍