Allow to ignore special character sequences for cy.type

[WiseBird]

Current behavior:

cy.type considers everything in {} as modifier sequence. In our app we have embedded code runner. For testing we put there code from fixtures with cy.type. And cy.type throws CypressError: Special character sequence: '{...}' is not recognized when code includes some braced expression.

Desired behavior:

Add option to cy.type to not treat {} as modifier sequence.

Versions

Cypress: 3.2.0

[jennifer-shehane]

@WiseBird You can type {{} to type the literal { key as shown in the docs, so this should work:

cy.get('input')
  .type('{{}mycommand}')
  .should('have.value', '{mycommand}')

Looks a little bit funky, but we had to choose some character, happened to be {

[WiseBird]

@jennifer-shehane Yes, I can escape them. But as I said we type source code, it can be quite big. You need to go through it and find all lines with both { } and then escape. Replacing all { with {{ wont work as if there is no } cypress will type both characters.

Wouldn't it be much easier to simply say that there is no control sequences?

[jennifer-shehane]

We could probably add an option to type like, 'charSequences: false`. This will be pretty low priority for our team to work on though, since it is possible to achieve what is needed for this to work.

We are always welcome to pull requests.

Code for .type(): https://github.com/cypress-io/cypress/blob/develop/packages/driver/src/cy/commands/actions/type.coffee#L24
Tests for `.type(): https://github.com/cypress-io/cypress/blob/develop/packages/driver/test/cypress/integration/commands/actions/type_spec.coffee#L1143

[WiseBird]

Sorry for my stupidity. While looking at tests I got how escaping really works.

[WORMSS]

I don't know if it's possible to re-open this request? or if I should open a new issue?
having to do

cy.get(el).type(myMessage.replace(/{/g, '{{}')).type('{enter}');

much nicer to have

cy.get(el).type(myMessage, { commands: false }).type('{enter}');

I will admit it doesn't make the code anyshorter, but much easier to read the intent of the action.

Reason this has become an issue is because we are dealing a lot with inputting mustache type strings into inputs and there is always someone who forgets this and spends a while trying to work it out.

[jennifer-shehane]

Another pretty reasonable argument for allowing an options argument to turn off special chars #4491

[cypress-bot]

The code for this is done in cypress-io/cypress#4744, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

[brian-mann]

We need to rename this option to be parseSpecialCharSequences: false to couple the option with the intended behavior in an affirmative way - as opposed to inverting it with disable*: true.

[brian-mann]

@cypress-io/test-runner someone feel free to open a new PR fixing this.

[kuceb]

I suggest reverting this altogether, and you can simply have a function that escapes your string:

const rawTypeString = (str) => str.replace(/{/g, '{{}')
cy.type(rawTypeString('{hello}'))

As bonus, its even more readable, since I get told I'm passing a rawTypeString before I even know the string

[WORMSS]

The whole point of this, is to remove the crappy str.replace.

[jennifer-shehane]

We decided to provide an option to .type(), but rename is to parseSpecialCharacterSequences. This will be part of our next feature release. If you want to download the pre-release version to use this new feature there are instructions here: 50a285a#commitcomment-34434312

The code for this is done in #4761, but this has yet to be released. We'll update this issue and reference the changelog when it's released.

[cypress-bot]

Released in 3.4.1.

[RubenGarcia]

Can you also add documentation? A search for "parseSpecialCharacterSequences cypress" in google only returns this page.
Edit: the option was renamed to parseSpecialCharSequences and is available at
https://docs.cypress.io/api/commands/type.html#Arguments