Re: [Bug 28131] New: Currently the spec defines switching to window by handle only, does it need by name too?

You're over simplifying things. Sure, we could run everything through
execute_script, but then we'd have Selenium 1.0 and would be limited by the
JavaScript sandbox.

* execute_script runs in the current context. The moment you trigger
navigation, you lose that context and the ability to track when the
navigation has completed. You could work around this with using two windows
(e.g. Selenium RC), but you're still limited to a single domain.

* For cookies, you can only read (name, value) pairs - and HttpOnly cookies
wouldn't be accessible either.

* For find_element, yes, you can do this through JS (most existing driver
implementations do). The problem is reusing elements (e.g. mouse clicks).
There is an inherent race in computing an element's location and issuing
the click. Computing click coordinates on the client increases the
likelihood of loosing the race, so it's more efficient to do it on the
server. Hence the whole WebElement reference mechanism (that and not having
to re-crawl the DOM every time).

To the point at hand, yes there is a balancing act. You seem to be arguing
it doesn't add much complexity, so why not support it. I'm arguing that the
added convenience doesn't justify increasing the surface area or complexity
of what implementors should be required to support.

-- Jason

On Wed, Mar 4, 2015 at 9:03 AM James Graham <james@hoppipolla.co.uk> wrote:

> On 04/03/15 16:42, Jason Leyba wrote:
> > That use case can be solved in client libraries and shouldn't require
> > extra complexity at the spec/protocol level.
>
> I think that argument applies to almost every command though. All of
> navigation, all of findElement[s], adding cookies, most of element
> state, and lots of other parts of the protocol could be implemented
> purely in clients in terms of execute_script. AIUI there is no design
> goal to find the minimal possible protocol, but to find some useful
> compromise between minimalism and implementation complexity.
>
> AFAICT the current design that uses an opaque set of WebDriver-only
> window identifiers is not the right point on that complexity curve; it
> makes doing simple things hard and the benefits are unclear.
>
>