- From: Andreas Tolfsen <ato@mozilla.com>
- Date: Sat, 18 Oct 2014 14:37:53 +0100
- To: Seva Lo <vlotoshnikov@gmail.com>
- Cc: public-browser-tools-testing <public-browser-tools-testing@w3.org>, David Burns <dburns@mozilla.com>
On Fri, Oct 17, 2014 at 8:57 PM, Seva Lo <vlotoshnikov@gmail.com> wrote: > 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. Sure, but we don't know anything about what additional capabilities a remote end supports. I think the best we can do is to _suggest_ that the remote returns a non-successful response with a value that is a string with some arbitrary reason why a session couldn't be provided. Would that work for you? > I agree, with anything like described above, a standard order or > consideration of the capabilities is important for interoperability. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27097
Received on Saturday, 18 October 2014 13:38:22 UTC