- 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