This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
All browsers agree that setting location.protocol to an invalid protocol throws. However, only IE throws when setting HTMLAnchorElement protocol.
I cannot reproduce this. If I paste <script> try { location.protocol = "https" } catch(e) { w(e)} </script> into http://software.hixie.ch/utilities/js/live-dom-viewer/ it is not logging an exception.
(In reply to Anne from comment #1) > I cannot reproduce this. If I paste > > <script> try { location.protocol = "https" } catch(e) { w(e)} </script> > > into > > http://software.hixie.ch/utilities/js/live-dom-viewer/ > > it is not logging an exception. How is "https" an invalid protocol? location.protocol = 'x y z' SyntaxError: Failed to set the 'protocol' property on 'Location': 'x y z' is an invalid protocol.
My bad. It's not entirely clear how I can write this into the specification with the current setup. I can observe scheme not having changed, but that does not necessarily mean the input was invalid (it could be the same scheme).
Simon, once you implement the API in Rust you want to take this into consideration.
Gecko also throws when setting it to an "unknown" scheme, definition of "unknown" unclear. It's not entirely clear to me what Chrome does when setting it to e.g. "x" for instance. It seems to not throw, but also not change the scheme.
Two ways of addressing this in the specification: 1. We make the URL parser return failure even for state override invocations. 2. We create an algorithm specifically for parsing the scheme. 1 should be pretty easy.
1 is complicated by the checks that do not allow you to change from a special scheme to a non-special scheme and vice versa, which we want for <a>, <area>, and URL. It seems for Location however, that should not throw, but should likely also not result in a scheme change. (Scheme change seems mostly relevant for "http" -> "https".) We could of course sometimes return failure and sometimes terminate steps (equivalent to returning void in IDL terms). A bit confusing perhaps, but it would result in what we want here.
Thank you for the report. Digging into this further I discovered that Location works all kinds of incorrectly if we put it logically on top of URLUtils. I filed https://github.com/whatwg/url/issues/61 which we'll use to get this sorted out.