Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a Window Timeout Field in the Command Editor, for Commands Marked as Opening a Window #1829

Closed
AlexGarrity opened this issue May 14, 2024 · 6 comments

Comments

@AlexGarrity
Copy link
Contributor

馃殌 Feature Proposal

When a command is marked as opening a window, a text field should be available to specify the timeout for opening the window.
I have a sample implementation of the feature on a fork of the repo, available here

Motivation

I use Selenium IDE to test a website which occasionally has quite long page load times. As a consequence of this, the default 2 second timeout on opening a window is too short, and frequently causes tests to fail when they're actually fine. It's possible to change this behaviour by editing the .side file itself, but it's not exactly the cleanest way of doing it.

Example

You have a page that's going to take at least 2 seconds to load due to server-side rendering, and Selenium IDE is failing the test because it's taking too long. You change the timeout to a longer duration, using the window timeout field, and now it passes as expected - without having to manually tweak the .side file.

@AlexGarrity AlexGarrity changed the title Window Timeout Field in Command Editor, for Commands Marked as Opening a Window Add a Window Timeout Field in the Command Editor, for Commands Marked as Opening a Window May 14, 2024
@toddtarsi
Copy link
Contributor

I would like that very much! Very clean fork btw!

@AlexGarrity
Copy link
Contributor Author

Thanks for the kind words - I'll drop in a PR now (although the Chinese translation may need some work)

@toddtarsi
Copy link
Contributor

@AlexGarrity - No worries there, a couple of Chinese users are contributors here, so if it's rill bad, they can just fix it.

@AlexGarrity
Copy link
Contributor Author

There are a couple of bits in the PR template regarding changes to documentation and testing - should I sort those out before putting the PR in?

@toddtarsi
Copy link
Contributor

Nah! I'd need to create documentation for you to edit first 馃槄 . Your code looks good, if the CI passes I'm happy. I'll work on cutting a release later tonight, although it might take me an extra day or two. I finally realized I wasn't building for M1 Macs, so the build pipeline is kinda broken while I get universal working on Mac OS.

@AlexGarrity
Copy link
Contributor Author

AlexGarrity commented May 14, 2024

Alright, no worries then - PR submitted. I remember from my limited experience of doing Mac OS builds that they can be a right pain, so best of luck with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants