Do not rely on WebDriver control flow for internal Synchronization

[sjelin]

As per SeleniumHQ/selenium#2969, the web driver control flow is going away. Internally, this means functions like browser.get need to be changed slightly to work via promise chaining instead of needing the control flow.

[nerumo]

I'm currently using async/await and I have some strange issues that might be related to this:

• if I use 'await browser.pause()' it does not stop immediately, it continues with the next items and then pauses somewhere later.
• if I pause the execution and try to continue (ctrl+d), I get a "connection reset" error and the process dies. continue one step on the other side is working

I never experienced these issues before I started using async/await and since I read here that there are some problems with async/await, it might all be related to it. What do you think? btw, I'm on windows 10 and node 6.8.0

[sjelin]

Are you using await for all asynchronous activity? We haven't done much testing but it pretty much ruins the WebDriver control flow, so I wouldn't be surprised if you had some issues.

[cletusw]

Since Typescript is adding async/await support in 2.1 due this month, it might be best to hold off on this issue. async/await code will be a much simpler diff coming from this serialized, managed promise world.

[sjelin]

We can't use async/await internally regardless for reasons too complicated to get into

[nerumo]

@sjelin 99% async/await. I try to remove the other 1% and try again

[nerumo]

the await browser.pause() seems to work now. the debugger detaching still doesn't work. @cletusw what do you think will change with 2.1? the generated output? from what I know is that 2.1 will only contain a ES5 version for async/await, but I target ES2015.

[cletusw]

It also added the ability to target ES2015, so your async/await will just
become generators/yield.

[sjelin]

The problems with async/await are not going away, regardless of how it's compiled (see SeleniumHQ/selenium#3037). You might just hang to hang in until we fix everything in https://github.com/angular/protractor/projects/2

[nerumo]

wow, WebStorm now supports protractor out of the box and debugging works like a charm, especially with everything async. btw, upgrading to nodejs 7 resolved the debugger detach problem.
so far I did not have problems with browser.get(), but I get that I just might be lucky so far.

[sjelin]

Blocked on #3884

[sjelin]

Closed in favor of everything in Stage 0 and Stage 1 of the Support ControlFlow-less Selenium project.

[xnnkmd]

What is the status of async/await support. There are several great examples provided by @sjelin that seems to indicate it works with SELENIUM_PROMISE_MANAGER=false but it is unclear how much trouble one might get into now if using (only) async/await ?

[afterbangx]

@xnnkmd I can tell you that my experience so far with async/await has been pretty good. I've been switching all of our tests over the last couple of weeks to use async/await instead of promise.Promise<T> and it has actually worked well. The tests seem to be more reliable. Even tests that have been considerably unreliable in the past are running now without issue using async/await. There were definitely some hurdles in the beginning but now that the majority of our tests have been switched over it's worked really well. There are still a few kinks to work out but the majority of my experience with async/await has been great. I've noticed a lot less "it works on my machine ¯\(ツ)/¯" comments now. For context, we have 46 page objects and roughly 250 tests.

[xnnkmd]

@afterbangx Thanks a lot for sharing your experience. I am also very keen on using async/await. Did run into a n initial issue though, which is that browser.pause does not work (#4184). So with async/await tests will be a bit harder to debug/diagnose (but easier to write/read).

What kinks did you run into ?