Support for Native Browser Events

[brian-mann]

click

• simulated click fixes #2956
• on text-editable click in center move the cursor to the end
  • ensure possible in IE11 without causing side effects
• cy.body().type():
  • blur focused element, send events to body
• support .rightClick() 🆕

possible:

• move cursor to beginning if click('left') or click('topleft') ⚠️

not fixed:

• document.execCommand("copy") does not work in cypress #2851 (execCommand will not work with untrusted events)

type

• by default issues native events
• force:true skips actionability and uses simulated keys
• simulated keys have no delay ⚠️ change from 50ms
• native keys by default have no delay ⚠️ change from 50ms
• support new special .type() sequences: {moveToEnd},{moveToStart} 🆕
• support new special .type() sequences: {tab},{shift+tab} 🆕
• type follows focus ⚠️
• trusted native keyboard events 🆕
  • checkValidity() returns true instead of false for min length on input #1930

{moveToEnd}/{moveToStart}

• IE: setSelectionRange on all inputs
• chrome/ff: setSelectionRange except for email/number inputs. For those we use execCommand('selectAll') + selection.modify('...')
• branch logic based on browserFeatures object. For ex)

{
  setSelectionRangeOnAllInputTypes: true
}

focus

• .focus behavior on certain text editable elements
  • command should first focusable element ⚠️ change from subject
  • focus host contenteditable #2717

contenteditable

• treated as any other text-editable in the commands above.
• By default move cursor to end
• support {moveToEnd}/{moveToStart}
• support {tab}

file uploads 🆕

• proposal #170
• tbd

cy.hover 🆕

• proposal #10
• tbd

scroll behavior

• scroll into view only if needed ⚠️
  • use getElementFromPoint on the pixel needing click
• scroll into center by default ⚠️
• allow user to configure scroll position (center, bottom, top) Enable users to change the scrolling strategy #871 🆕
  For IE:
  • scrollIntoView can't center, so calculate coords and try to center it manually

Considerations / Research

select text command? 🆕

• allow user to make arbitrary text selection

mouse state

• tbd

for mouse actions that involve mouse state:

• in open mode, warn if potentially affected test
• includes click (since hover before click), hover, drag-and-drop

For IE11 & firefox, see branch issue-311-ie-ff

[brian-mann]

With the release of Chrome 63 we can now finally do this.

We'll begin by adding { native: true } to existing commands for users to opt into using the native variants of them.

From there we'll add new commands for file uploads, etc.

We can also expose a low level command for talking directly to the debugger protocol to expose all of the other power and goodness that extends well beyond WebDriver.

[bahmutov]

👏👍🎉

…

Sent from my iPhone

On Oct 26, 2017, at 18:56, Brian Mann ***@***.***> wrote: With the release of Chrome 63 we can now finally do this. We'll begin by adding { native: true } to existing commands for users to opt into using the native variants of them. From there we'll add new commands for file uploads, etc. We can also expose a low level command for talking directly to the debugger protocol to expose all of the other power and goodness that extends well beyond WebDriver. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mateatslc]

good news, sounds exciting! 👏

[dziamid]

Awesome! Is it devtools compatible? Do you plan to eventually deprecate the not-native commands?

[brian-mann]

It is dev tools compatible.

We will definitely not ever deprecate the non-native commands because they are actually more precise (as long as they work correctly). Non native can be issued synchronously and it's impossible to miss coordinates.

Native events will always be async, so if we ask for them to fire at a specific coordinate, it will take take before it's actually issued. If there are state changes by then - you have a failure.

We'll likely have a few native commands only like .attach() or something. But then enable you to opt into the native commands for commands we already have.

[dwelle]

Does this mean we'll able to invoke and test :hover/:active pseudo classes?

[brian-mann]

Yes

[zth]

Is there a plan to integrate file uploading better with native events landing? There's a comment about it here cut I cannot seem to find any more information about it.

[atomboulian]

My question is the same as @zth. Seems like this would be true, but I just want to confirm. There are medium articles talking about file uploads not being supported, even in February of this year.

[jpike88]

Just curious where things are at? I can't get a good reading on how close this functionality is to being ready or if it is already available

[brian-mann]

@Bkucera is starting on this work this week. We've gone through the game plan and will begin implementing this and all of the other work orthogonal to native events.

[egucciar]

@brian-mann will this change some of the known "permanent limitations" of Cypress? One example being something like performance testing, which with integration with Dev Tools could totally be within reach

[kilrain]

Piling onto this mega-ticket: It'd be really great if Cypress fired the beforeInput event for cy.type. Without beforeinput support, my team is blocked from adopting Cypress as we use the Slate.js contenteditable library.

Related Slate ticket

From the docs;

beforeinput is not fired even though it is in the spec because no browser has adopted it.

The above isn't true... Chrome, Edge and Safari have all implemented the spec and Firefox is well on their way.

[reydelo]

@kilrain Hopefully the Cypress team will update their input commands to dispatch the beforeinput event, but until they do I’ve created a couple of simple custom commands which will trigger Slate’s input event listeners and make it respond ianstormtaylor/slate#3476 (comment)

[devtreehouse]

I saw this item being taken down from cypress road map page. Does that mean this item is not going to be brought up anytime soon?

[jennifer-shehane]

@devtreehouse Having native browser events support is not in current development. It is still part of our future roadmap.

We updated our published roadmap to reflect what is in active development - not necessarily every feature we plan to do in the future, but we intend to improve upon this communication in the coming months.

[dwelle]

@jennifer-shehane if Cypress exposed Chrome Devtools Protocol API (as suggested in #5670 (comment)), then we could implement something in userland.

[dmtrKovalenko]

Published a package that implements native events using CDP connection (via cypress.automation hook). This should be a great start for native events at cypress 🐣.

https://github.com/dmtrKovalenko/cypress-real-events

[moritzWa]

For those that found themselves here looking for a solution: https://github.com/Bkucera/cypress-plugin-tab

[dmtrKovalenko]

@moritzWa it is not a real native browser event, so it won't work as a real browser tab. In order to make a real tab event use https://github.com/dmtrKovalenko/cypress-real-events and cy.realPress("Tab")

[rsudarson]

@dmtrKovalenko - Do cypress-real-events has support for drag and drop?

[Badlapje]

Would also really love this feature. Using cypress to test accessibility is not practical without native events.

Also: i cannot believe cypress not using native events isn't mentioned in the docs. There are several places where this should be made more clear. Eg. the page about cy.type. That page gives the impression you can emulate user behaviour, but for a11y purposes that's not true. I cannot select a label / button / link and type enter ... then get consistent results. See this ticket for more info.

[beaugunderson]

@Badlapje your second link is the same as the first :)

[Badlapje]

fixed it, thx @beaugunderson !

[yanfengliu]

Any progress on this? The minLength validation for <input> tag still cannot be triggered in Cypress 6.1

[dmtrKovalenko]

Mostly all native events are implemented at https://github.com/dmtrKovalenko/cypress-real-events