- From: James Graham <james@hoppipolla.co.uk>
- Date: Wed, 9 Sep 2015 15:03:51 +0100
- To: public-browser-tools-testing@w3.org
On 09/09/15 11:47, James Graham wrote: > On 07/09/15 16:36, Alexei Barantsev wrote: >> The "execute script" argument can be applied to this operation in >> general. >> >> I'll better vote +1 to remove it from the specification than to change >> the >> semantics. > > Having GET session/{session_id}/url return a different url to the one > set by the same path but with POST would be total nonsense. So if you > want to change the semantics of one you need to also change the > semantics of the other. > > Not providing a GET for this POST seems like poor design. > > Therefore I conclude that if you want to remove this you should also > remove the corresponding POST endpoint from the spec. These are > certainly things that can be implemented in the client with javascript, > but removing all such things is not a rule that has generally been > applied. If you did that, all of section 7 would disappear and much of > 10, 11, and 12 could go. > > Oh, I was mistaken. AFAIK you can't replicate the blocking behaviour of this command in JS, so assuming that's considered a desirable thing then the endpoint is necessary. On the other hand it seems theoretically possible to get blocking behaviour for navigating a subframe using js alone (execute_async_script + a load listener on the iframe element in the parent document).
Received on Wednesday, 9 September 2015 14:04:25 UTC