feat: Increase timeout to 5 minutes if a debugger is attached

[linkdotnet]

Closes #1177

[egil]

Why not disable timeout completely (TimeOut.Infinite)? That makes more sense to me.

I remember having that at some point. Cannot remember why I took it out again.

[linkdotnet]

Why not disable timeout completely (TimeOut.Infinite)? That makes more sense to me.

I remember having that at some point. Cannot remember why I took it out again.

Simplicity - we can not just have no timeout for timer.Change and it also doesn't except things like TimeSpan.MaxValue as it would throw an exception:

NotSupportedException
The dueTime or period parameter, in milliseconds, is greater than 4294967294.

^Source

[linkdotnet]

So in the end we would use some "arbitrary" value. Sure we can put it to another, higher value.

[egil]

Hmm you can just turn of the timer by passing in a https://learn.microsoft.com/en-us/dotnet/api/system.threading.timeout.infinite?view=net-7.0#system-threading-timeout-infinite as duetime/period.

[linkdotnet]

Fair point - updated the PR.

[egil]

Looks good.

Think we need to add a code doc as well as docs updates that remark to all WaitFor methods that tells the user about this feature.

[linkdotnet]

I added the docs - fun fact, as WaitForElement and WaitForElements don't have an optional timeout (TimeSpan? timeOut) - the trick doesn't work here. I was tempted to introduce an overload, but I guess it might make more sense to align this in v2 rather than adding more stuff to v1.
Let me know if you think differently here.

[egil]

Just update the remaining docs and then it looks alright.

Ps. Excuse the brevity. Reviewing from the car on my phone.

[linkdotnet]

Just update the remaining docs and then it looks alright.

Ps. Excuse the brevity. Reviewing from the car on my phone.