Bug 151613 - Changing URL.host should not override port
Summary: Changing URL.host should not override port
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Rob Buis
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-11-25 18:14 PST by Kinuko Yasuda
Modified: 2020-07-17 09:39 PDT (History)
10 users (show)

See Also:


Attachments
Patch (9.64 KB, patch)
2020-07-14 09:31 PDT, Rob Buis
no flags Details | Formatted Diff | Diff
Patch (9.76 KB, patch)
2020-07-14 11:20 PDT, Rob Buis
no flags Details | Formatted Diff | Diff
Patch (9.67 KB, patch)
2020-07-17 00:14 PDT, Rob Buis
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kinuko Yasuda 2015-11-25 18:14:25 PST
Repro step:
1. In JS console, type 
var u = new URL("http://host.tld:8888/path")
u.host
2.observe that result is "host.tld:8888"
3.type
u.host = "newhost.tld"
u.host
4. observe that result is "newhost.tld"

Per the specification the port is not changed, therefore the result should be "newest.tld:8888", which is what FF and Chrome do.
Comment 1 Kinuko Yasuda 2015-11-25 18:16:48 PST
This was originally filed on Chrome, while the spec seems to indicate Chrome and FF's behavior is the expected one.

https://code.google.com/p/chromium/issues/detail?id=551901#c8

(+annevk for potential spec issue)
Comment 2 Kinuko Yasuda 2015-11-29 23:40:37 PST
Looks like the spec now has clarification that the port should not be overridden if the given value for the .host does not have port part:

https://github.com/whatwg/url/commit/99a85f77e0edf2bcc9f73183eba6c50ef9706ded
Comment 3 Rob Buis 2020-07-05 14:32:23 PDT
Kinuko, is it true that this change was never done for Chrome? If so there may be less priority to change the behavior for WebKit (I am not sure what Firefox behavior here is though).
Comment 4 Rob Buis 2020-07-14 09:31:53 PDT
Created attachment 404241 [details]
Patch
Comment 5 Rob Buis 2020-07-14 11:20:35 PDT
Created attachment 404255 [details]
Patch
Comment 6 Alex Christensen 2020-07-14 20:16:25 PDT
Comment on attachment 404255 [details]
Patch

According to https://wpt.fyi/results/url/url-setters.html?label=experimental&label=master&aligned we currently match chrome and Firefox is the only browser following the spec/passing the wpt.  I think that is justification to not change this unless Chrome does.

Admittedly Firefox's behavior makes intuitive sense so I'd be willing to change if there's a consensus.
Comment 7 Rob Buis 2020-07-17 00:14:20 PDT
Created attachment 404543 [details]
Patch
Comment 8 Rob Buis 2020-07-17 00:16:34 PDT
(In reply to Alex Christensen from comment #6)
> Comment on attachment 404255 [details]
> Patch
> 
> According to
> https://wpt.fyi/results/url/url-setters.
> html?label=experimental&label=master&aligned we currently match chrome and
> Firefox is the only browser following the spec/passing the wpt.  I think
> that is justification to not change this unless Chrome does.

The patch to change the behavior just landed:
https://chromium-review.googlesource.com/c/chromium/src/+/2300103> Admittedly 

>Firefox's behavior makes intuitive sense so I'd be willing to
> change if there's a consensus.

Good to know!
Comment 9 EWS 2020-07-17 09:38:10 PDT
Committed r264516: <https://trac.webkit.org/changeset/264516>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 404543 [details].
Comment 10 Radar WebKit Bug Importer 2020-07-17 09:39:14 PDT
<rdar://problem/65729794>