add options to click, doubleClick, tap

[BryanCrotaz]

Add options to public api which are passed down to the relevant MouseEvent and TouchEvent

[BryanCrotaz]

@rwjblue build failed with a curl error - can't see how to rerun tests - are you able to?

[rwjblue]

Restarted

[rwjblue]

It seems really odd to me to have the same options for mousedown, mouseup, and click 🤔

[BryanCrotaz]

The common options are going to be button, x, y. Which options would you want to be different for each event?

[rwjblue]

Same concern here. If we are going to allow event options I think we need a system that allows us to customize each of the events individually...

@mmun and I had discussed this somewhat recently, but I can’t recall if we came to a good conclusion 🤔

[BryanCrotaz]

We’re simulating a click. We don’t need to do anything that the browser doesn’t do. Does the browser provide different data for each of these calls?

[bendemboski]

Maybe allow options to either be a POJO or a function, and if a function, gets invoked with the name of the event and its return value is the options POJO?

[sdhull]

👋 Hi! Absolutely love that you're working on this @BryanCrotaz, thank you!

I'm not sure what @rwjblue has in mind in terms of customizing "each of the events individually." What has been done in this PR makes perfect sense to me -- that is to say, you pass options through to fireEvent, which then constructs the event with some default options & merges the passed options in. That's what these helpers should do IMO.

And specifically for mousedown, mouseup and click, these events all appear to have the same properties according to MDN.

Perhaps @rwjblue is concerned with developers passing an option like charCode to a click event? Or clientX to a keyboard event? Personally I wouldn't worry about that in this PR.

Maybe in a followup PR we could add some checks to warn developers they're trying to use options that don't make sense, but for simply enabling a developer to specify specific coordinates in a click (or double-click or tap), I would urge maintainers to merge this to enable ambitious testing of our ambitious apps 😎

---

tl;dr -- 🙏 please merge this and ship a patch release so I can get off of @BryanCrotaz's branch 😬

[mmun]

@rwjblue This PR seems ok to me as is. My main concern would be passing the event options to unrelated kinds of events (e.g. passing mouse options to the focus event).

You could argue that the mousedown and mouseup events could have different options (if you move your mouse during the press), however even then I think it just makes more sense to manually trigger each event individually in your test.

tl;dr I think it's good as is.

BTW, thanks for putting this issue back on our radar @sdhull.

[BryanCrotaz]

I agree. The method is to simulate a click. If you want to simulate down-drag-up you wouldn’t use it - you’d definitely simulate individual events.

[cibernox]

I think it makes sense to pass the same options for both mousedown/mouseup and click. For instance, if the user is pressing shift, that key will be pressed for all three events.

It is true that there may be some situation where someone could desite to simulate each event of a click with different options (a mousedown in one x/y coordinate and a mouseup in different coordinates), but in those situation are uncommon and seems reasonable to ask the developer to resort to a lower-level approach, firing each even independently.

await triggerEvent('mousedown', { screenX: 1, screenY: 1 } );
await triggerEvent('mouseup', { screenX: 1, screenY: 5 } );

The current proposal sounds good. Is there anything else to do here?

[rwjblue]

Thank you!