Alternative for selenium v3 unsupported commands in v4

[NikhilHedau]

Hi @toddtarsi

Can you please provide the alternative for below commands in selenium v4? I have used the side-migrate npm package(https://www.npmjs.com/package/@seleniumhq/side-migrate) to migrate v3 files to v4 , but it seems to remove the commands. For submit command the package is neither replacing nor removing.

1. answerOnNextPrompt
2. chooseCancelOnNextConfirmation
3. chooseCancelOnNextPrompt
4. chooseOkOnNextConfirmation
5. debugger
6. submit

Thanks in advance.

[toddtarsi]

@NikhilHedau - Sorry for the delay in responding to this. Started to last night, but fell asleep.

1. It looks like side-migrate was initially overoptimistic for the prompt commands. Unfortunately, while electron does natively support alert and confirm, they do not natively support prompt:

https://github.com/electron/electron/issues/472

After reading your issues, I started working on keeping the v3 polyfill in here for now. I'm going to adjust the side-migrate script to keep in prompt commands, as they'll still be needed.

2. The IDE natively supports confirm and alerts, so the choose-next commands for these can go away. Generally, v3 would expect you to have two commands here. One beforehand that is chooseCancelOnNextConfirmation (for the JS polyfill), and one for the actual driver instrumentation which was like webdriver cancel confirmation or similar. Basically, in v4 those can go away for confirmations and alerts. The new equivalent here is just dismissConfirmation I believe.

3. Same as 1.

4. Same as 2, but the equivalent is acceptConfirmation.

5. I can look at adding this back, but I'm a bit confused at what the expected UX is here. Should I open the dev tools in the playback window and then inject the debugger script? Doing this would be easy, but I just want to make sure I properly transport whatever functionality you're looking for here.

6. So, this isn't something we want to support going forward, as calling form.submit() isn't really browser instrumentation, as much as its triggering an event directly. However, to make migrating not a total PITA, I'm going to add this back using driver instrumentation, and instead of throwing an error, it will just log a console error recommending to replace the 'submit' command with the actual initiating interaction 'click submit', 'hit enter', etc.

So, 1 and 3 is a bummer. I'm going to look at dropping those changes, and adding the bare minimum here so that it polyfills like v3, and then I might ask the electron team if there's a way I can help here further to enable native prompt support.

[toddtarsi]

Actually, I was looking last night, and I might be able to drop one and three as well. I think electron has a good enough mechanism to make prompts block the render thread, and should also be instrumentable via the standard selenium footprint.

[NikhilHedau]

Hi @toddtarsi , Thanks for the update. As per my understanding , I deduce the following points.

1. answerOnNextPrompt and chooseCancelOnNextPrompt commands will not be supported in v4. Alternatives that can be used are answerPrompt , acceptAlert, dismissPrompt.
2. chooseCancelOnNextConfirmation command's alternative is dismissConfirmation
3. chooseOkOnNextConfirmation command's alternative is acceptConfirmation.
4. debugger and submit will be supported in v4.

Can you please confirm if my understanding is correct?

[toddtarsi]

1, 2, and 3: Yep! 4: Yep, but the submit command will log a big nasty error text every time its used because its bad and browser/selenium mileage for it varies (its doing weird js stuff somewhere down there and isn't like an actual instrumented interaction like clicking or typing is).

[toddtarsi]

@NikhilHedau - Ended up writing polyfills for alert, confirm, and prompt. Nice part is that we're working from a NodeJS backend, so we can actually do thread render locking and stuff. It feels less like a shim and more like I just re-implemented these commands to spec.

[NikhilHedau]

@toddtarsi , Thanks for the update. I wanted to understand if your changes has any impact with respect to supported commands.

[toddtarsi]

@NikhilHedau - Nope! Just that all choose-next commands will be gone, and instead you should just use dismiss confirmation, accept alert, all of the same commands that would work just like they do in the side runner.

Although! I still have a question about debugger:

My assumption is that this should be a debugger in the playback window, so you'd expect that command to trigger a breakpoint in the test, open dev tools in the browser window, and then start a breakpoint in the JS code execution there as well?

[NikhilHedau]

@toddtarsi , Thanks for the clarification.

I am fine with the same behaviour as in selenium v3 which I guess does n't start a breakpoint in the JS code execution.

[BartolomeSintes]

I have noticed that the storeXpathCount command is not available in Selenium IDE v4 (checked in 4.0.1-alpha.72). What's the alternative to this command? By the way, is there a list of available commands in v4 (something like https://www.selenium.dev/selenium-ide/docs/en/api/commands)?

[toddtarsi]

This should migrate you to v4 automatically:

https://www.npmjs.com/package/@seleniumhq/side-migrate

It's not so nice visually, but this should give you the list:

https://github.com/SeleniumHQ/selenium-ide/blob/trunk/packages/side-model/src/Commands.ts

[BartolomeSintes]

Thank you very much for your help. The list is very useful and I have found in it the storeElementCount command. I have installed the side-migrate and it has indeed converted storeXpathCount commands with storeElementCount commands. By the way I would say that there is a typo in https://www.npmjs.com/package/@seleniumhq/side-migrate?activeTab=readme. npx @seleniuhq/side-migrate ./existing_file.side ./new_v4_file.side should be npx @seleniumhq/side-migrate ./existing_file.side ./new_v4_file.side ie, @seleniumhq instead of @seleniuhq

[toddtarsi]

@BartolomeSintes - 😄 Thank you!

PR from your recommendation here: https://github.com/SeleniumHQ/selenium-ide/pull/1752

Similarly, if you ever want an easy way to run selenium-ide, it supports npm i -g selenium-ide and just being run as selenium-ide now. It's a bit messy because it uses the electron binary directly without truly building a release image, so the desktop icon is the electron icon, but it is a pretty nice workflow if you're using npm imo.

[BartolomeSintes]

I have just tried the npm selenium-side. As you have said, it seems to be an easy way to use the trunk version of selenium IDE. To be honest ;-), so far, I have had only tried alpha-72 of selenium IDE v4 (installed using the installer available in the releases page). I have been very pleased by its speed, comparing to the Firefox Selenium IDE v3 extension. Today I have tried alpha-74 in windows and I have noticed some changes. alpha-72 opens 4 electron windows but alpha-74 opens only one (I don't know which one is the intended UI). My use case of Selenium IDE is perhaps a little bit special, as I create the .side files writing them directly, not using Selenium-IDE. I am a teacher of Computer Science in a Spanish post-secondary vocational school. My pupils are trying to learn PHP ;-) and I provide them with .side files in order to help them test some of their programs. In this context, speed is welcomed so we all would be glad if Selenium-ide v4 becomes stable. So thank you very much for your work! 👍

[toddtarsi]

Oh wowie! That's awesome, please let me know if I can help in any way. I just switched it to 1 window last release. I think it makes for a more consistent workflow (I kept losing track of my logger window), so I'm going to have it be 1 window going forward. Before I take it completely out of beta, I'm going to spend the next week or two making sure it feels good. I have a very short list of things left to do before I'm done at this point. 😄

1. Playback window right click shortcuts for matchers and convenience methods (wait for text, wait for element visible, wait for element present, wait for attribute, open dev tools).
2. Fake browser top bar (search url / tabs) to give people better playback window controls.
3. Adding more testing for the IDE (there are ~400 tests on the shared runtime, ~100 tests on the side runner, and 0 on the IDE because it both instruments and is instrumented by electron-chromedriver, which makes my head hurt).
4. Writing a bunch of pages here: https://github.com/SeleniumHQ/selenium-ide/wiki/Selenium-IDE-v4