Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Native Browser Events #311

Open
brian-mann opened this issue Nov 24, 2016 · 37 comments
Open

Support for Native Browser Events #311

brian-mann opened this issue Nov 24, 2016 · 37 comments

Comments

@brian-mann
Copy link
Member

@brian-mann brian-mann commented Nov 24, 2016

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 馃啎

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
Copy link
Member Author

@brian-mann brian-mann commented Oct 26, 2017

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
Copy link
Contributor

@bahmutov bahmutov commented Oct 26, 2017

@mateatslc
Copy link

@mateatslc mateatslc commented Oct 27, 2017

good news, sounds exciting! 馃憦

@dziamid
Copy link

@dziamid dziamid commented Nov 2, 2017

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

@brian-mann
Copy link
Member Author

@brian-mann brian-mann commented Nov 2, 2017

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
Copy link

@dwelle dwelle commented Nov 4, 2017

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

@brian-mann
Copy link
Member Author

@brian-mann brian-mann commented Nov 4, 2017

Yes

@zth
Copy link

@zth zth commented Jan 17, 2018

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
Copy link

@atomboulian atomboulian commented Apr 27, 2018

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
Copy link
Contributor

@jpike88 jpike88 commented Jun 2, 2018

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
Copy link
Member Author

@brian-mann brian-mann commented Jun 12, 2018

@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
Copy link
Contributor

@egucciar egucciar commented Jul 24, 2018

@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
Copy link

@kilrain kilrain commented Apr 7, 2020

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
Copy link

@reydelo reydelo commented Apr 22, 2020

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

@devtreehouse
Copy link

@devtreehouse devtreehouse commented May 1, 2020

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
Copy link
Member

@jennifer-shehane jennifer-shehane commented May 4, 2020

@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
Copy link

@dwelle dwelle commented May 4, 2020

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

@dmtrKovalenko
Copy link
Member

@dmtrKovalenko dmtrKovalenko commented Nov 22, 2020

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
Copy link

@moritzWa moritzWa commented Nov 29, 2020

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

@dmtrKovalenko
Copy link
Member

@dmtrKovalenko dmtrKovalenko commented Nov 29, 2020

@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
Copy link

@rsudarson rsudarson commented Dec 1, 2020

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

@Badlapje
Copy link

@Badlapje Badlapje commented Dec 14, 2020

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
Copy link

@beaugunderson beaugunderson commented Dec 14, 2020

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

@Badlapje
Copy link

@Badlapje Badlapje commented Dec 15, 2020

fixed it, thx @beaugunderson !

@yanfengliu
Copy link

@yanfengliu yanfengliu commented Dec 29, 2020

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

@dmtrKovalenko
Copy link
Member

@dmtrKovalenko dmtrKovalenko commented Dec 30, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.