Bug 28954 – hostname and host are mixed up when manipulating anchor elements

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Yael]

From http://dev.w3.org/html5/spec/infrastructure.html#interfaces-for-url-manipulation:

o . host [ = value ]
    Returns the current host and port (if it's not the default port) in the underlying URL.
    Can be set, to change the underlying URL's host and port.
    The host and the port are separated by a colon. The port part, if omitted, will be assumed to be the current scheme's default port.
o . hostname [ = value ]
    Returns the current host in the underlying URL.
    Can be set, to change the underlying URL's host.


In the current implementation of HTMLAnchorElement, they are mixed up.
FireFox and IE are following the spec while WebKit, Safari and Opera are not.

[Yael]

Created attachment 39012 [details]
Patch

[Darin Adler]

Comment on attachment 39012 [details]
Patch

Change looks good. This needs a regression test. You should be able to test it with a test in the "http" part of the LayoutTests directory.

[Yael]

Created attachment 39064 [details]
Patch

Added a test as requested in #2.

[Yael]

Landed in r48063.

[Darin Adler]

What about a port number of 0? This code seems to do the wrong thing in that case. Maybe you could do a separate patch that adds test cases for that case.

[Yael]

(In reply to comment #5)
> What about a port number of 0? This code seems to do the wrong thing in that
> case. Maybe you could do a separate patch that adds test cases for that case.

You are right, when the href includes port 0, my patch does not handle it correctly. I will fix it shortly.

[Alexey Proskuryakov]

*** Bug 20608 has been marked as a duplicate of this bug. ***

[Yael]

Created attachment 39089 [details]
Patch

Added handling for when port is 0, including a new test case.

[Yael]

Due to additional comments, I am reopening this bug.

[Darin Adler]

Comment on attachment 39089 [details]
Patch

> +    if (url.hostEnd() == url.pathStart())

I think it's slightly unclear to code it this way. I'd prefer to have a hasPort() function on KURL. In fact, at one point these hostEnd() and pathStart() functions didn't exist, and I'm not sure we'll want to keep them in the long run.

But I guess this is OK as-is for now. I won't insist on changing KURL.h.

r=me

[Eric Seidel (no email)]

Comment on attachment 39089 [details]
Patch

Clearing flags on attachment: 39089

Committed r48107: <http://trac.webkit.org/changeset/48107>

[Eric Seidel (no email)]

All reviewed patches have been landed.  Closing bug.