Re: Proposal: Setting all capabilities to required

Andreas,

When you say "we don't know why they're failing for non-standard
capabilities", what do you mean?

If we (the local end) do not know why sessions failed to start, more
information from the remote end will only help. Of course, often the
browser just won't start or other component will malfunction and then the
driver won't know much to report (could be an environment error or a
transitional glitch), so it will return error message(s) as it does now.
But if the session couldn't be started because certain specific capability
couldn't be met (by the end driver or an intermediary such as Java Selenium
server or a grid node), that's would be something to report back for the
local end to know.


I agree, with anything like described above, a standard order or
consideration of the capabilities is important for interoperability.

Seva

On Oct 3, 2014 3:35 AM, "Andreas Tolfsen" <ato@mozilla.com> wrote:

> I hit the send but accidentally.
>
> On Fri, Oct 3, 2014 at 11:31 AM, Andreas Tolfsen <ato@mozilla.com> wrote:
> > On Fri, Oct 3, 2014 at 12:21 AM, Seva Lo <vlotoshnikov@gmail.com> wrote:
> >> Related here. When POST /session returns an *error*, details of the
> >> *reasons* why the request was denied may become more important if all
> >> capabilities are required.
> >
> > I agree that would be nice, but it's meaningless to specify that
> > drivers must return a sensible error message when we don
>
> 't know why they're failing for non-standard capabilities.
>
> However you're right that specifying error handling of matching the
> specified capabilities would be important.  For example all drivers
> should match the capabilities in an orderly manner, so that not one
> driver checks browserName first and another browserVersion.  Currently
> we only suggest an ordering in
>
> https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#h4_remote-end-matching-of-capabilities
> .
>

Received on Friday, 17 October 2014 19:57:52 UTC