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.
Created attachment 39012 [details] Patch
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.
Created attachment 39064 [details] Patch Added a test as requested in #2.
Landed in r48063.
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.
(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.
*** Bug 20608 has been marked as a duplicate of this bug. ***
Created attachment 39089 [details] Patch Added handling for when port is 0, including a new test case.
Due to additional comments, I am reopening this bug.
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
Comment on attachment 39089 [details] Patch Clearing flags on attachment: 39089 Committed r48107: <http://trac.webkit.org/changeset/48107>
All reviewed patches have been landed. Closing bug.