I have created a login.json file through chrome recorder and copied it to cypress\downloads. Now when I run "npx @cypress/chrome-recorder cypress\downloads\login.json" OR "npx @cypress/chrome-recorder cypress\downloads\login.json --print" .

I am getting the error "There was an issue writing the output to cypress/integration. Please check that it exists and try again.".

Can anybody help me on this. Thanks

Chrome 109 launches a new "Copy a single step as script" feature.

How to test

• In a recording, right click on a step, select copy as [your extension] script option.

Action required

• Your extension needs to implement the stringifyStep API for this feature to work.
• You can test this feature with the latest Chrome Canary

A recorder hover event will be mapped to cy.get("#element").trigger("mouseover");.

I'm aware of this is not a 1-1 match as trigger event in cypress only works for element with javascript function (e.g. mouseover). For element with native css:hover, it doesn't trigger the UI changes.

Closes #29.

Refer to:

• https://docs.cypress.io/api/commands/hover#Add-as-a-custom-command
• https://github.com/cypress-io/cypress/issues/10

Test pages:

• This will work: hover with JavaScript mouseover event
• This doesn't work: hover with native css

User facing changelog

Changes the output files type from .spec to .cy as per Cypress v10 changes.

How has the user experience changed?

No change on user action. Any new files generated will output as filename.cy instead of filename.spec.

This PR adds support for the keyDown step type. It enables support for special sequences found in both DevTools Recorder and the cy.type documentation.

Fixes #14.

Add ability to handle assertedEvents that happen after a user clicks a link.

Output is:

cy.get("{selector}").click();
cy.location("href").should("eq", "{url}");

User facing changelog

Changes the output files type from .spec to .cy as per Cypress v10 changes.

How has the user experience changed?

No change. Any new files generated will output as filename.cy instead of filename.spec.

When a click-type event has button: 'secondary', the output will be cy.get("_element_").rightclick();.

A doubleClick event will become cy.get("_element_").dblclick();.

Closes #20.

Hey there! 👋

We have extended the Schema in @puppeteer/replay with some new attributes for the click step and a new step type called double click:

1. https://github.com/puppeteer/replay/blob/main/src/Schema.ts#L66
2. https://github.com/puppeteer/replay/blob/main/src/Schema.ts#L87

It'd be great to update the cypress recorder to support those. The feature will be shipping in Chromium 103.

I tried doing a fairly simple recording, or so I thought.

Went into our ERP and added a part. I ran the tool, and got this:

Cypress does not currently handle migrating step type: keyDown
Cypress does not currently handle migrating step type: keyUp
... 

It does seem to generate some files, with the text that I had entered, but the errors kind of threw me. I think this would nearly aways generate such errors if there is more to the recorded session than statically clicking on a page, so some mention of what this error means, and when or if it can be ignored would be good.

My guess is this can be ignored?

1. I have a recordings folder with a user flow json file in it.
2. Run npx @cypress/chrome-recorder recordings
3. Hit error EISDIR: illegal operation on a directory, read [NOT OK]

Expect all user flow JSON in the recordings folder are converted successfully.

Run npx @cypress/chrome-recorder recordings/order-a-coffee.json to convert a single JSON file is successful without error [OK].

Currently the repo doesn't handle publishing. We need to generate and add this manifest.json file as part of the yarn build step:

{
  "manifest_version": 3,
  "version": "1.1.0",
  "name": "Cypress Chrome Recorder",
  "description": "Cypress extension for DevTools that allows you to export tests directly from the Recorder panel.",
  "permissions": [],
  "devtools_page": "DevToolsPlugin.html",
  "content_security_policy": {
    "extension_pages": "script-src 'self'; object-src 'self'"
  },
  "minimum_chrome_version": "104.0.0.0",
  "icons": {
    "16": "icon_16x16.png",
    "32": "icon_32x32.png",
    "48": "icon_48x48.png",
    "128": "icon_128x128.png"
  }
}

Ideally we could then make the publishing automated as part of CI if possible as well

When clicking on and choosing a option within a select, the code generated on cypress export creates cy.get('element').type('value of option')

I believe when the element is of type select/option and the event is change we should do a cy.get('element').select('value or label of option selected') instead.

We simple select a value from a dropdown, export it, run the test in cypress and the select does not work properly.

environment: Windows system step: when execute npx @cypress/chrome-recorder D:\workspace\UIAutoTest\cypress811\cypressuinew\cypress\e2e\recording\record.json -o=D:\workspace\UIAutoTest\cypress811\cypressuinew\cypress\e2e\recording error detail: Running Cypress Chrome Recorder on D:\workspace\UIAutoTest\cypress811\cypressuinew\cypress\e2e\recording\record.json There was an issue writing the output to D:\workspace\UIAutoTest\cypress811\cypressuinew\cypress\e2e\recording. Please check that it exists and try again.

DevTools Recorder support text and XPath selector from Chrome 108 onwards. I am wondering if there are similar selector in Cypress?

Here is the example step's json.

{
      "type": "click",
      "target": "main",
      "selectors": [
        [
          "aria/Proceed to checkout"
        ],
        [
          "[data-test=checkout]"
        ],
        [
          "xpath///*[@data-test=\"checkout\"]"
        ],
        [
          "text/Total: $0.00"
        ]
      ]
    }

This PR adds security controls in support of vulnerability scanning for third party packages as well as first party code.

Snyk is already implemented, but these actions bring the Cypress Tools into alignment with our vulnerability management strategy. The actions that this pull request introduces send the scan results back to the Snyk dashboard. The Snyk dashboard is then coupled with branch protection rules that dictate our levels of protection by blocking PRs where this git action fails as a check.

Once the solution is fully implemented, the failures you see on the PR related to this would prevent merges of the code to the 'develop' and 'master' branches. The exit status it failed with today indicates that there is a critical vulnerability in the code base. This PR aims to increase this type of visibility.