Thinking of a new paradigm for recording

[chenglou]

It'd be really great if the user doesn't have to juggle between the terminal and the browser. The only way to do that is to have the screenshot taking action happen in the browser. Two options:

1. Assign a keyboard shortcut. Could introduce a fast screen flash to indicate screen capturing.
2. Automatically take screenshot at each relevant event. Stuff like key entering could get a delay before capturing screenshot.

Both open doors to the possibility of removing the distinction between live replay and ordinary chained replay, since without the windows switching delay the whole testing can be replayed live without too much useless time gaps. Reducing the remaining time gaps can be done by Huxley itself when relevant, i.e. between keystrokes.

[jhnns]

Sounds interesting. Juggling between the terminal and the browser is really distracting and annoying when I record something.

Automatically take screenshot at each relevant event. Stuff like key entering could get a delay before capturing screenshot.

I'm not sure about this. I think that it is more flexible if I'm able to specify when a screenshot has to be taken. I end up editing the delays manually anyway.

[chenglou]

I've written down more thoughts locally. Option 2 is probably not doable realistically speaking. It's a cool idea though. What makes you edit the delay?

[jhnns]

Some delays are too short. It worked while recording, but they're too short for automated testing since we don't want false positives. And others are far too long because I needed to switch between the terminal and the window (and I needed some time to think about which button to press, maybe I need a new cpu :smile:).

[chenglou]

Just to clarify: the short and long delays are all intentionally done by you using l right? There's no weird race condition when replaying without live playback on non-animated tests?

[jhnns]

Yep, I'm always pressing the l button. I'm still experimenting, but it seems like my tests are working fine. I haven't used the live playback option, just starting huxley with hux.

[chenglou]

Just so that we're on the same page: live playback is l. If you don't have any transition or ajax wait, you don't need l btw, just normal enter.

[jhnns]

Yes, I know. I'm working with l because I have transitions on my html elements. I thought that this might be a problem if the screenshot is taken immediately after the user interaction.

[chenglou]

Ah, alright. Yeah this is probably never gonna an exact timing because of selenium's own delays. Anyways, I guess realistically I'll go with the first path, if I ever do.

[jhnns]

Is selenium adding a delay between actions? If yes, is it just a rigid default value or determined by some event?

[chenglou]

I think it's just slow lol. It's faster for the chome driver. I chain up the calls without delay (unless there's an explicit pause).