Inconsistent values of anchor element IDL attributes compare to other vendors |
||||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Example URL:
Steps to reproduce the problem:
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<script>
var link = document.createElement("a");
link.href = "scheme://domain.com:80/path";
alert("link.protocol:" + link.protocol);
alert("link.host:" + link.host);
alert("link.pathname:" + link.pathname);
</script>
</body>
</html>
What is the expected behavior?
Needs to be discussed. Currently
IE:
link.protocol:scheme:
link.host:domain.com:80
link.pathname:path
Firefox:
link.protocol:scheme:
link.host:
link.pathname:
What went wrong?
Chrome:
link.protocol:scheme:
link.host:
link.pathname://domain.com:80/path
Does it occur on multiple sites: N/A
Is it a problem with a plugin? N/A
Did this work before? N/A
Does this work in other browsers? N/A
Chrome version: 54.0.2795.0 (Developer Build) (64-bit) Channel: dev
OS Version: Ubuntu 14.04
Flash Version:
,
Jul 15 2016
Spec: https://html.spec.whatwg.org/multipage/semantics.html#htmlhyperlinkelementutils Implementation: Source/dom/DOMURLUtilsReadOnly.*
,
Jul 15 2016
I'm pretty sure I've seen other bugs about Chrome being inconsistent with URL parsing in the URL object, but casual searching now didn't find them. Whoever works on this should look at URL constructor too; I think they bottom out in GURL and have the same issues.
,
Jul 15 2016
I couldn't find either. I can work on this one since I reported it in the first place :)
,
Jul 15 2016
I have a question about URL scheme. From the spec: A scheme must be one ASCII alpha, followed by zero or more of ASCII alphanumeric, "+", "-", and ".". Schemes should be registered in the IANA URI [sic] Schemes registry. [IANA-URI-SCHEMES] [RFC7595]. If a scheme is not registered in IANA URI does it mean that the url with the scheme is malformed? The spec says it "should" be registered, not "must". Firefox doesn't seem to parse host and other parts of the url if the scheme is unknown.
,
Jul 15 2016
After some investigation, since in this example URL scheme is "scheme" and isn't standard scheme (see https://chromium.googlesource.com/chromium/src.git/+/lkcr/url/url_util.cc#23) So it treats the url as a path URL only, see https://chromium.googlesource.com/chromium/src.git/+/lkcr/url/url_util.cc#222. Which probably is not right since it is only correct for data: or javascript: urls. So for unknown schemes it should either ignore the url part after scheme completely or parse it as a generic standard url.
,
Jul 19 2016
Hi guys, further to my comments above I made a WIP patch: https://codereview.chromium.org/2159203002/. This change follows Firefox example not to parse the url host and other parts of the url if the scheme is unknown. Quite many URL related layout tests will fail now since the default parsing has changed with the patch. Please have a look, and lets discuss what would be the right approach.
,
Jul 19 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 21 2017
,
Jul 23
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 25
,
Aug 3
It's very risky to change any part of Chrome's URL parsing or canonicalisation, as it affects every part of the browser that processes URLs. Because URLs often represent security boundaries, such changes require extensive scrutiny. In general we only do them if they are very low risk and/or high reward.
,
Aug 3
,
Aug 3
Same as Issue 869291?
,
Aug 6
#14 Yeah this is the exact same issue as Issue 869291. Even though this is (much) older, I'm going to dupe it in the other direction, since my issue is more general (it's clear that it's an issue in the URL parser, not the anchor attributes), and has an analysis of the issue with reference to the Chromium code and the spec.
,
Aug 6
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by rnimmagadda@chromium.org
, Jul 14 2016Components: Blink>HTML>Parser
Labels: -Type-Compat M-52 OS-Mac OS-Windows Type-Bug
Status: Untriaged (was: Unconfirmed)
1.4 MB
1.4 MB Download