w3c / webdriver

Remote control interface that enables introspection and control of user agents.
https://w3c.github.io/webdriver/
Other
680 stars 195 forks source link

Supporting `await` in Execute Script #1436

Open jugglinmike opened 5 years ago

jugglinmike commented 5 years ago

There's been some talk about supporting await in the Execute Script and potentially Execute Async Script. This could be a great improvement, but it needs a little more definition before we can move on it.

The answer to the first question seems to be "yes," but it would be nice to have verification here in the project's issue tracker.

2 is possible if we're willing to make inferences on developer intent based on the type of the return value (i.e. if it's a "thenable", then ignore the callback function).

I think believe that is the only way to implement 2. If that's right, then 3 may not be feasible. If Execute Async Script were interpreted with an async function, then it would always return a thenable, and we would have no way to determine when to wait for the invocation of the callback function.

Personally, I think we should consider Execute Async Script a legacy API and not bother with any enhancements to it.

whimboo commented 5 years ago

Note that we already have tests which make use of await: https://github.com/web-platform-tests/wpt/blob/master/webdriver/tests/execute_script/promise.py

Would those have needed such a spec change before being allowed to land?

jugglinmike commented 1 week ago

The relevant tests have moved:

css-meeting-bot commented 1 week ago

The Browser Testing and Tools Working Group just discussed Supporting await in Execute Script.

The full IRC log of that discussion <jgraham> Topic: Supporting await in Execute Script
<jgraham> github: https://github.com/w3c/webdriver/issues/1436
<jgraham> jugglinmike: I filed this issue 5 years ago, and let it drop, but I'd like to pick it back up to gauge interest. Should `await` be supported in `execute script` in WebDriver classic, or indeed `execute async script` where it means whether the script is considered async. There are already wpt that assume this. Chrome and Safari pass, but Firefox has
<jgraham> an open bug.
<jgraham> jugglinmike: Not sure what the status of Firefox is, or is intended to be. Not sure what needs to change here. Either update classic to match the implementations of Chrome and Safari or update wpt to remove the tests if we think the behaviour is wrong.
<jgraham> q+
<tidoust> scribe+
<jgraham> ack next
<AutomatedTester> q?
<tidoust> jgraham: Since it's purely a superset, it makes sense to me to include it.
<jugglinmike> scribe+ jugglinmike
<tidoust> ... I don't know when we'll get to it in Firefox
<tidoust> ... but that seems reasonable in any case.
<jgraham> jugglinmike: There's a potential problem using promises to model async operations because we don't have an environment settings object. I don't know if I can do this cleanly. THat's something that will require further discussion. But I'm happy to worry about that later.
<jgraham> jugglinmike: seems like I can get to work on updating the spec.