RE: Go command and invalid URLs

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).

*
*> 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..."

Received on Wednesday, 11 May 2016 20:55:41 UTC