W3C home > Mailing lists > Public > public-browser-tools-testing@w3.org > April to June 2016

RE: Go command and invalid URLs

From: John Jansen <John.Jansen@microsoft.com>
Date: Wed, 11 May 2016 20:55:11 +0000
To: Andreas Tolfsen <ato@mozilla.com>, "public-browser-tools-testing@w3.org" <public-browser-tools-testing@w3.org>
Message-ID: <CY1PR0301MB1995E2D357282FB41FFE29B3F1720@CY1PR0301MB1995.namprd03.prod.outlook.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:53 UTC