Re: Go command and invalid URLs

On Wed, May 11, 2016 at 9:55 PM, John Jansen <John.Jansen@microsoft.com>
wrote:

> Chiming in for small points...
>
> *> Passing an invalid URL to the Get command results in an error.
> *> Relative URLs are also considered to be invalid. Browsing to
> *> about:blank and chrome://settings does work, although javascript: URLs
> *won't.
> *
> *The "javascript" scheme is mentioned in the URL spec, but not "chrome".
> *I’d say that it’s fine for Chrome to support chrome://. Other browsers may
> *not support, say ftp:// in the future.
>
> I would not expect us to spec any "vendor prefixed" protocols such as
> "chrome://", rather I think we should leave it as generic as "invalid URLs"
> (which would include "chrome://" when testing Firefox or Edge, for example).
>

The spec should say as little as possible about how browsers should handle
URLs (I suspect "absolute only" and "handle self-signed certs" are the two
main criteria needed). My opinion is that if the browser follows a vendor
prefixed protocol, and that page ends up being HTML then it should be
possible to control those pages using WebDriver, should the browser vendor
feel that's desirable (I can imagine something like "chrome://" might be
sensitive) Defining the schemes that WebDriver supports feels like
something that's out of scope for us.

*
> *> I don't think a full simulation of the omnibox/address bar belongs in
> *> WebDriver, and implementing it might cause confusion and interop
> *> issues (for certain inputs, some browsers would trigger a search while
> *> others would perform a navigation).
> *
> *Furthermore, development browsers or “browser shells”, such as Servo and
> *Chrome’s content shell, may not have all the necessary features to handle
> *malformed URLs.
> *
> *> I'd be fine with adding a new error status code for this, if others
> *> think it would be useful.
> *
> *I think it’s better than the generic “WebDriverException” that is being
> used
> *now. Error classification by type can be useful in this context.
>
> There are additional concerns like "invalid in the current context" such
> as trying to browse file:// in the current security context. Or maybe
> res:// . I'm not sure if the Error status should be specific, or simply
> "URL seems to be invalid..."
>

The general error is probably better, since different browsers will handle
failures in very different ways.

Simon