Bug 158869 - URL hash setter does not remove fragment identifier if argument is an empty string
Summary: URL hash setter does not remove fragment identifier if argument is an empty s...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: Safari 9
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-06-17 04:59 PDT by Robert Knight
Modified: 2016-06-17 15:42 PDT (History)
8 users (show)

See Also:


Attachments
Patch (15.40 KB, patch)
2016-06-17 11:17 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Knight 2016-06-17 04:59:27 PDT
According to the spec for the `URL.hash` setter in https://url.spec.whatwg.org/#urlutils-members , assigning an empty string to a URL's hash should remove the fragment identifier. In WebKit however it sets it to an empty string. The result is that the following will produce a 'http://example.com/' in Chrome/Firefox but 'http://example.com/#' in Safari.

var url = new URL('http://example.com');
url.hash = '';
console.log(url.toString());
Comment 1 Radar WebKit Bug Importer 2016-06-17 09:24:45 PDT
<rdar://problem/26863430>
Comment 2 Chris Dumez 2016-06-17 11:17:58 PDT
Created attachment 281569 [details]
Patch
Comment 3 Darin Adler 2016-06-17 12:58:30 PDT
Comment on attachment 281569 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=281569&action=review

> Source/WebCore/html/URLUtils.h:287
> +    String newFragment = value[0U] == '#' ? value.substring(1) : value;

Would be better if some day setFragmentIdentifier was changed to take a StringView, then we would not have to allocate a new string just to contain a substring of what we were passed.
Comment 4 WebKit Commit Bot 2016-06-17 13:18:56 PDT
Comment on attachment 281569 [details]
Patch

Clearing flags on attachment: 281569

Committed r202176: <http://trac.webkit.org/changeset/202176>
Comment 5 WebKit Commit Bot 2016-06-17 13:19:02 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 Chris Dumez 2016-06-17 13:23:51 PDT
@Robert Knight: You should be able to test/verify the fix using tomorrow's nightly build at https://webkit.org/nightly/
Comment 7 Robert Knight 2016-06-17 15:42:11 PDT
Wow! That's a fast turn around. Thank-you both!