Support for Native Browser Events #311
Comments
With the release of Chrome 63 we can now finally do this. We'll begin by adding 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. |
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.
|
good news, sounds exciting! |
Awesome! Is it devtools compatible? Do you plan to eventually deprecate the not-native commands? |
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 |
Does this mean we'll able to invoke and test |
Yes |
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. |
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. |
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 |
@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. |
@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 |
Piling onto this mega-ticket: It'd be really great if Cypress fired the
The above isn't true... Chrome, Edge and Safari have all implemented the spec and Firefox is well on their way. |
@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) |
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? |
@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. |
@jennifer-shehane if Cypress exposed Chrome Devtools Protocol API (as suggested in #5670 (comment)), then we could implement something in userland. |
Published a package that implements native events using CDP connection (via |
For those that found themselves here looking for a solution: https://github.com/Bkucera/cypress-plugin-tab |
@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 |
@dmtrKovalenko - Do cypress-real-events has support for drag and drop? |
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. |
@Badlapje your second link is the same as the first :) |
fixed it, thx @beaugunderson ! |
Any progress on this? The minLength validation for |
Mostly all native events are implemented at https://github.com/dmtrKovalenko/cypress-real-events |
click
IE11
without causing side effectscy.body().type()
:blur
focused element, send events tobody
.rightClick()
possible:
click('left')
orclick('topleft')
not fixed:
type
force:true
skips actionability and uses simulated keys.type()
sequences:{moveToEnd}
,{moveToStart}
.type()
sequences:{tab}
,{shift+tab}
{moveToEnd}/{moveToStart}
execCommand('selectAll') + selection.modify('...')
browserFeatures
object. For ex)focus
.focus
behavior on certain text editable elementscontenteditable
{moveToEnd}
/{moveToStart}
{tab}
file uploads🆕
cy.hover🆕
scroll behavior
For IE:
Considerations / Research
select text command?🆕
mouse state
for mouse actions that involve mouse state:For IE11 & firefox, see branch issue-311-ie-ff
The text was updated successfully, but these errors were encountered: