W3C home > Mailing lists > Public > public-browser-tools-testing@w3.org > July to September 2015

Re: How to get URL of the page opened in the current frame?

From: James Graham <james@hoppipolla.co.uk>
Date: Wed, 9 Sep 2015 15:03:51 +0100
To: public-browser-tools-testing@w3.org
Message-ID: <55F03C47.3070109@hoppipolla.co.uk>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 9 September 2015 14:04:25 UTC