feat: can dispatch events with the type they want.

[sainthkh]

• Closes Inconsistant and invalid Events Typing using cypress #5650
• Closes cy.trigger('mousedown', ...) doesn't fill in event.view property #3686

User facing changelog

Users can dispatch events with the type they want. And the event is an instance of UIEvent, view property is filled with AUT window.

Additional details

Why was this change necessary?

• Some users want to use the correct type of Event with cy.trigger(). But it was impossible.
• view property didn't replicate the behavior of the browsers.

What is affected by this change?

N/A

Any implementation details to explain?

At first, I tried to implement this with an object map like below:

const eventMap = {
  'mousedown': 'MouseEvent',
  'keydown': 'KeyboardEvent',
  etcetra,
}

Because trigger can find the correct automatically. But the problem is that most of the properties of Events are read-only. They cannot be modified even with _.extend.

It's a big problem because you cannot fire MouseEvent like:

let options = {
        clientX: 42,
        clientY: 24,
        pageX: 420,
        pageY: 240,
        foo: 'foo',
      }

MouseEvent constructor doesn't get pageX and pageY properties and they are automatically set to the values of clientX and clientY.

So, I had to give up eventMap and introduce eventType option instead.

How has the user experience changed?

cy.$$('input').then($el => {
  $el.get(0).addEventListener('mousedown', (e) => {
    // e is an instance of AUT window MouseEvent
    // e.view is AUT window.
  })
})

cy.get('input').trigger('mousedown', {
  eventType: 'MouseEvent'
})

PR Tasks

• Have tests been added/updated?
• Has the original issue been tagged with a release in ZenHub?
• Has a PR for user-facing changes been opened in cypress-documentation? => Update trigger doc with new eventConstructor option cypress-documentation#3078
• Have API changes been updated in the type definitions?
• [N/A] Have new configuration options been added to the cypress.schema.json?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[jennifer-shehane]

I'm not totally in love with calling this option eventType since there is a literal event.type that would be the name of the event.

But, looking through all the docs for this it seems they mostly refer to this as an 'interface', see https://w3c.github.io/uievents/#interface-keyboardevent

Would an 'interface' key even make sense? Probably not. @chrisbreiding any thoughts? Maybe the current naming is harmless.

[chrisbreiding]

I'm not totally in love with calling this option eventType since there is a literal event.type that would be the name of the event.

I agree that's problematic and could be confusing.

I don't think I like interface though. It's more of a keyword used for type definitions.

We could use constructor since that's exactly what this property refers to.

cy.trigger('mousedown', {
  constructor: 'MouseEvent',
})

[jennifer-shehane]

@sainthkh What do you think of the name constructor for this new option?

[sainthkh]

I think it's better. It's less confusing. I'll change it that way.

[sainthkh]

constructor is always defined in browsers. That's why there are a lot of failures below.

You can check it out by just opening a console window and try the code below:

I thought of writing code like below to avoid this problem, but it's too unintuitive.

const constructor = typeof options.constructor === 'string' ? options.constructor : 'Event' 

I came to the conclusion that we cannot use the name, constructor.

My proposal: How about naming it eventClassName or eventInterfaceName?

[jennifer-shehane]

😞 maybe eventConstructor? @chrisbreiding thoughts?

[chrisbreiding]

I was worried that would be an issue. Let's go with eventConstructor.

[sainthkh]

Flaky failures.