You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would allow for async/await support without breaking the control flow. It would be an option, not the default, and we'd pick a name in the Protractor config that made it obvious that this feature would be risky. Potential pitfalls:
Some other code might try to do the same thing, and I see no way to merge two classes like we do with patched functions (i.e. you can't "call" the original class like you do with functions).
Someone might save the global Promise somewhere before we overwrite it (for example, selenium does this, though this case isn't a problem for us).
This would break instanceof tests, though we could patch the webdriver.promise.Promise class to inherit from the global Promise
This would break equality tests, though why you might do that I don't know.
This could have other unexpected behavior
In the internal implementation of selenium-webdriver, they sometimes use native promises. Presumably, it could cause a problem if they accidentally used webdriver.promise.Promise instead. I don't think this would be a problem though because they're require()'d first and make a point of saving the global Promise to a local variable.
Savvy users might be aware of the difference between webdriver.promise.Promise and the global Promise class, and want to avoid using a webdriver promise for some reason
The webdriver.promise.Promise might behave differently than the global Promise in some unforeseen way
This is hacking and something unexpected could go wrong.
Once async/await are native to JS, it's unclear what this will do.
The text was updated successfully, but these errors were encountered:
This would allow for
async
/await
support without breaking the control flow. It would be an option, not the default, and we'd pick a name in the Protractor config that made it obvious that this feature would be risky. Potential pitfalls:Promise
somewhere before we overwrite it (for example, selenium does this, though this case isn't a problem for us).instanceof
tests, though we could patch thewebdriver.promise.Promise
class to inherit from the globalPromise
selenium-webdriver
, they sometimes use native promises. Presumably, it could cause a problem if they accidentally usedwebdriver.promise.Promise
instead. I don't think this would be a problem though because they'rerequire()
'd first and make a point of saving the globalPromise
to a local variable.webdriver.promise.Promise
and the globalPromise
class, and want to avoid using a webdriver promise for some reasonwebdriver.promise.Promise
might behave differently than the globalPromise
in some unforeseen wayasync
/await
are native to JS, it's unclear what this will do.The text was updated successfully, but these errors were encountered: