feat: mask values typed into input[type=password] in a reporter

[wentwrong]

Purpose

Values typed into input[type=password] should be replaced by a placeholder before sending action logs with these values to a reporter. Also the pressKey and the typeText actions have the confidential flag. If it set to 'true', then any typed text & pressed keys would be replaced by a placeholder in action logs.

Approach

Detect what is the target element (either specified in the typeText action or current active element for the pressKey action). If it's the input which type is 'password' or the confidential flag is set to true, then replace info with a placeholder.

References

Closes #6014

Pre-Merge TODO

• Write tests for your proposed changes
• Make sure that existing tests do not fail

[miherlosev]

It's better to put down the confidential property to the basic classes and set the false as a default value.

[wentwrong]

void 0 is necessary as a default value. It's needed to indicate that a user didn't set this flag explicitly.

I've tried to use enum for this flag, but it looks overcomplicated in my opinion (ts-hack to create 3-state boolean):

enum ConfidentialSetting {
    False,
    True,
    CheckRequired
}

Now by default, this option will be shown in the "options" property of the command:

{
    type:    TYPE.typeText,
    options: {
        confidential: 2 // or the "CheckRequired" string (not better)
    }
}

Whereas void 0 wouldn't be set at all. I think it's better to stick with the void 0 variant.

[miherlosev]

It's not clear what the void 0 value means in the context of the confidential option.
So, in my opinion, the enum ConfidentialSetting is a good variant.

@AndreyBelym what do you think about it?

[AndreyBelym]

IMHO:
TLDR; I'm against a tri-state enum:

1. In this enum, 2 of 3 values just replicate boolean options. For me, it's a sign of redundant complexity.

2. I can't see any case when I would want to specify ConfidentialSetting.CheckRequired manually. Why should we give it a name, if a user won't interact with it?

3. I can describe easily the boolean configuration:
   If true, we hide the input value
   If false, we show the input value
   By default, it's true when the target selector is input[type=password], false otherwise.

[AndreyBelym]

Well, about point 2: I see a case, if we implement some global-level options, you may want to reset this flag to default in some cases. But since undefined is a common way to reset something to default in JS everywhere, I don't see it as a problem.

[miherlosev]

Ok. Let it be.

[miherlosev]

It's not clear what the void 0 value means in the context of the confidential option.
So, in my opinion, the enum ConfidentialSetting is a good variant.

@AndreyBelym what do you think about it?

[miherlosev]

"../ts-defs-src"
Why does it necessary? I as remember we have a separate Gulp step for the TypeScript definitions.

[AndreyBelym]

I guess it should test the compatibility between our end-user TS defs and our source-level defs.

[wentwrong]

I've added the end user TS defs in order to reuse them in the source code and don't maintain two versions of the same TS defs.

For example NodeSnapshot was already defined in the end-user TS defs:

testcafe/ts-defs-src/test-api/node-snapshot.d.ts

Line 29 in c72b8cd

interface NodeSnapshot {

Also the CompilerOptions interface was defined too:

testcafe/ts-defs-src/runner-api/runner-api.d.ts

Line 108 in c72b8cd

type CompilerOptions = {

[AndreyBelym]

IMHO:
TLDR; I'm against a tri-state enum:

1. In this enum, 2 of 3 values just replicate boolean options. For me, it's a sign of redundant complexity.

2. I can't see any case when I would want to specify ConfidentialSetting.CheckRequired manually. Why should we give it a name, if a user won't interact with it?

3. I can describe easily the boolean configuration:
   If true, we hide the input value
   If false, we show the input value
   By default, it's true when the target selector is input[type=password], false otherwise.

[miherlosev]

The last issue - https://github.com/DevExpress/testcafe/pull/6191/files#r628129446