Summary: | host and hostname properties return incorrect (opposite) values | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Vladimir Olexa (vladinecko) <vladimir.olexa> | ||||
Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED DUPLICATE | ||||||
Severity: | Normal | CC: | ap | ||||
Priority: | P2 | ||||||
Version: | 525.x (Safari 3.1) | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.5 | ||||||
Attachments: |
|
Description
Vladimir Olexa (vladinecko)
2008-09-02 14:34:28 PDT
Created attachment 23126 [details]
Test case
simple test case to showcase the bug
I believe we do it this way to match IE. like many other things in IE, this is one of those that completely doesn't make sense and is counterintuitive. wouldn't we rather want to match firefox in behavior? (In reply to comment #2) > I believe we do it this way to match IE. > Better test case: http://old.przemoc.net:81/host.html Location is a kind of link, so if location's host and hostname properties works in every browser exactly the same, then it must be truth for ordinary links. Results (Windows): Gecko (Fx 3) - correct IE 5/6/7 - correct WebKit (Chrome, Opera 9.5, Safari 3.1) - incorrect Thanks, confirmed as a difference with IE 7 and Firefox 3. (In reply to comment #4) > WebKit (Chrome, Opera 9.5, Safari 3.1) - incorrect Please note that Opera doesn't use WebKit. Maybe there is a reason behind this quirk if two engines have it -but on the linked test case, it seems to be clear that we are in error. |