lifaon74 / url-polyfill Goto Github PK

It seems url-polyfill is not detecting an incorrect behaviour from edge and therefore not polyfilling the whole URLSearchParams with standard behaviour. Even if I add the polyfill before the code, it falls back to edge behaviour which breaks the code, requiring custom browser workaround.

Failing code:

const formData = new FormData(event.target);
alert(new URLSearchParams([...formData.entries()]).toString());

SSCCE that fails on Edge and includes the polyfill in "resources": https://jsfiddle.net/v138s4x2/

If you use spread, it works. Here's my workaround at the moment:

const formData = new FormData(event.target);
alert(new URLSearchParams([...formData.entries()]).toString());

The reason is outlined here:

The problem in Edge is that they do not support destructuring of FormData object. (for ... of in linked table).

Expected behavior:

The polyfill detects and intercepts the faulty behavior from Edge and overrides URLSearchParams with standard behavior

This project is very good, I like it too, thank you for your contribution.

I think that instead of changing the global environment, it is better to provide a bundle in UMD format, so that some projects that do not want to change the global environment can be introduced according to their own needs.

This line of code causes a crash if document is not available:

https://github.com/lifaon74/url-polyfill/blob/master/url-polyfill.js#L262

This makes the package not usable in non-browser contexts, namely React Native.

Parsing http:/localhost/ with the native URL returns

{
  hash: "",
  host: "localhost",
  hostname: "localhost",
  href: "http://localhost/",
  origin: "http://localhost",
  password: "",
  pathname: "/",
  port: "",
  protocol: "http:",
  search: "",
  searchParams: {},
  username: ""
}

polyfill returns

{
  hash: "",
  host: "",
  hostname: "",
  href: "http://localhost/localhost/",
  origin: "http://",
  password: "",
  pathname: "/localhost/",
  port: "",
  protocol: "http:",
  search: "",
  searchParams: {},
  username: ""
}

Looks like older versions of firefox (v29->v44) don't support .entries() and so code like:

new URLSearchParams().entries()

is broken for those browsers. Should url-polyfill kick in for these?

(see also vercel/next.js#15194)

Hi, after update to 1.1.0, we are getting this error in IE11:

Object doesn't support property or method '_fromString'

in this peace of code:

this.searchParams._fromString(this.search);

Previous version of the polyfill worked fine.

I have no idea why this happens...

Also it would be nice to separate URL and URLSearchParams polyfills so we could use only one of them, and replace the other one with something else in cases like this.

Best regards!

First of all, thank you for crafting a concise and excellent library. Our product runs into native code barfing with new URL in mobile Safari on iOS and I played around with your standalone classes and found them to be a perfect fit. Wondering if you have a public release planned with these classes soon.

const url = new URL('http://echo/')
url.searchParams.set('qux', 'baz')
console.log(url.toString())

....
http://echo/?[object Object]

FWIW, was able to resolve things trivially with the following port from url-polyfill.js:

URLSearchParams.prototype.toString = function () { 
  var pairs = []; 
  this.forEach(function (value, name) { 
    pairs.push(encodeURIComponent(name) + '=' + encodeURIComponent(value)); 
  }); 
  return pairs.join('&'); 
}; 

toString() {
  const pairs = [];
  this.forEach(function (value, name) {
    pairs.push(encodeURIComponent(name) + '=' + encodeURIComponent(value));
  });
  return pairs.join('&');
}

I used this url-polyfill to validate the URL provided by the user and while testing in IE I realized that the behavior in IE and Google Chrom is completely different.

The function where I am using the url-polyfill is this:

The logs in Chrome is this (which is correct behavior for "sdfdsfdsf" provided as a URL):

The logs in IE is this (which is not expected for the "sdfdsfdsf" provided as a URL):

Version of IE: 11.0.9600.18860
Version of Chrome: 64.0.3282.186
Environment: VM - Windows 7 (32)

Given the following code:
new URLSearchParams('?external_url=https://test.com/?plan=team&step=2').toString()

Results in:
external_url=https%3A%2F%2Ftest.com%2F%3Fplan&step=2

Expected:
external_url=https%3A%2F%2Ftest.com%2F%3Fplan%3Dteam&step=2

Here's a page i made in glitch (w/ some weird CDN stuff) that shows the issue. AFAIK, based on MDN, the initializer is optional. Here's what i was reading: https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams

https://tan-brazil.glitch.me/

The change from #61 adds a 'toLowerCase' call to the base variable. The code assumes that the value passed to the base argument is always a string. However, it's also possible to pass an existing URL object to both arguments. The values should both be stringified, but only the url argument is currently stringified.

Passing an URL object to the base argument results in the following error:

Object doesn't support property or method 'toLowerCase'

In Chrome pathname of a mailto URL outputs the e-mail address.

console.log(new URL('mailto:[email protected]').pathname);
// -> "[email protected]"

But using the url-polyfill it's prefixed with /.

console.log(new URL('mailto:[email protected]').pathname);
// -> "/[email protected]"

Hi,

I am trying to use this api in NodeJS.
Fails because window is undefined inside NodeJS.
Should be able to attach this api to global.
Suggest removing window check.

Using nasty workaround to get it working:

const window: any = (global as any).window = global;
window.location = {};

With Kind Regards,
Albert Willemsen

Got the following error:

TypeError: Cannot read property 'apply' of undefined
  apply (webpack:///node_modules/url-polyfill/url-polyfill.js:305:0),

Raised when calling url.searchParams.set(key, value);

User agents:

Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36

I used the url.js to polyfill URL and URLSearchParams on the server since it didn't use document. But that file is moved to do-not-use/url.js now. url-polyfill.js uses document in the constructor and basically just acts as a API on top of an DOM <a> so that doesn't work. Why shouldn't we use url.js?

The following code should throw an Invalid URL error:

new URL('/foo')

As of now, in both IE11 and Safari, window.location.href is assumed as base.

I am trying to use this in a react native project. When I do:

import 'url-polyfill'

console.log('URL:', URL);
console.log('url:', new URL('http://www.google.com?inq=true&q=1#inh=true&h=1'));

It errors with:

document is not defined

Is it possible to use this in a non-DOM scope?

Input:

new URL('http://a.com')

Output:

{
  ...
  href: 'http://a.com/',
  origin: 'http://a.com:80',
  port: '80',
  ...
}

Expected (as is in Chrome):

{
  ...
  href: 'http://a.com/',
  origin: 'http://a.com',
  port: '',
  ...
}

Edit: this consequence seems to occur in IE only :/

Input

new URL('/part', 'http://servername:80/app');

Result in error: 'URL unable to set base http://servername/app due to http://servername:80/app'

Another problem is that the address must be lowercase due to case-sensitive string comparison, i.e. I can not write

new URL('/part', 'http://SERVERNAME/app');

= simbol is allowed as a url param value.

Example:
new UrlSearchParams('?param1=valuewith=&param2=bar');

This example breaks un the unexpected value: {param1: valuewith , param2: bar}

expected: {param1: valuewith= , param2: bar}

Just curious - is this meant to work in node? I was hoping it would so I can run unit tests there without mocking out the URL/URLSearchParams APIs. This is the error:

$ cat test.js
require('url-polyfill')
u = new URL('https://example.com/')
$ node test.js
/Users/jrz/node_modules/url-polyfill/url-polyfill.js:174
      var doc = document.implementation.createHTMLDocument('');
                                        ^

ReferenceError: document is not defined
    at new URL (/Users/jrz/node_modules/url-polyfill/url-polyfill.js:174:41)
    at Object.<anonymous> (/Users/jrz/test.js:3:5)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:383:7)
    at startup (bootstrap_node.js:149:9)
$ node -v
v6.12.0

Since we are checking if URLSearchParams is present in the global variable, we should also then instantiate URLSearchParams from the global variable. So instead of new URLSearchParams it should be new global.new URLSearchParams, since URLSearchParams is not necessarily the same as global.URLSearchParams.

Fix:

 if (!('URLSearchParams' in global) || (new global.URLSearchParams('?a=1').toString() !== 'a=1')) { 
   polyfillURLSearchParams(); 
 } 

Search debugger in url-polyfill.min.js, you can find: ...function(e){debugger;var t=function()....
It may cause unexpected issue, please checkout and fix it, thanks.

It's working great on all other browsers

currently every time get searchParams will create a new object, which is waste memory and cause problem.
currently, in chrome 49.

const url = new URL('http://example.com/?a=1');
url.searchParams.set('b','2')
url.searchParams.set('c','3')
console.log(url.toString())

=>

http://example.com/?%3F%3Fa=1&b=2&c=3

will get some mysterious %3F in search string, seems it's caused by duplicated searchParams create.

btw, chrome 49 support both URL and URLSearchParams, but no url.searchParams.
this may help you debug.

well no i guess wrong.
only one searchParams call will cause this problem too.

const url = new URL('http://example.com/?a=1');
const params = url.searchParams;
params.set('b','2');
params.set('c','3');
console.log(url.toString())

=>

http://example.com/?%3Fa=1&b=2&c=3

I found that.

this version of chrome native URLSearchParams doesn't cut leading ?

in chrome 49

new URLSearchParams('?a=1').toString() #=> "%3Fa=1"

in chrome 60

new URLSearchParams('?a=1').toString() #=> "a=1"

seems these should be more check before using native URLSearchParams, like

  if(!('URLSearchParams' in global && new URLSearchParams('?a=1').toString() === 'a=1')) {
    polyfillURLSearchParams();
  }

Seems the URLSearchParams implentation is not consistent with the Firefox and Chrome behavior.

Using Chrome 63 and Firefox 57:

let url = new URL('https://www.example.com/?key=hello+world');
url.searchParams.get('key');

The result is: "hello world"

Using the polyfill and the same code in Edge 16, the result is:
"hello+world"

Thanks for this project! I see versions have been "released" in the package.json file, but I'm wondering if you could also tag the releases in GitHub?

Ideally we’d add some unit tests for #54.

If passing an object to the URL constructor, in Firefox and Chrome it will use the toString() property of the object as the URL to process. This is most obvious (and useful) when passing a Location object such as window.location.
The polyfill does not do this; it simply checks if the parameter is typeof string, and if not it throws an exception.

Line 173 of url-polyfill.js should be either removed or accept objects and call their toString() method.
Before the line
if(typeof url !== 'string') throw new TypeError('Failed to construct \'URL\': Invalid URL');
we can add
if (typeof url === 'object') url = url.toString();
which will solve the problem

This polyfill is broken for e.g. Safari 10 since Version 1.1.X.
Please fix this!

JS error from console:

this.searchParams._fromString is not a function.

IE11: If I do
test = new URLSearchParams({ a: 1, b: 2})
When I do test.toString(), I get an error.

But if I do
test = new URLSearchParams('a=1&b=2')
When I do test.toString(), I don't get an error.

Both works in other browsers.

I found a small inconsistency with native Chrome implementation when trying to delete search param.

Here is the test case:

// OK
it('should preserve the same string if no param to delete', function () {
  let url = new URL('https://www.example.com/?bar=1');
  url.searchParams.delete('foo');
  expect(url.toString()).to.equal('https://www.example.com/?bar=1');
});

// expected 'https://www.example.com/?' to equal 'https://www.example.com/'
it('should preserve the same string if no any params to delete', function () {
  let url = new URL('https://www.example.com/');
  url.searchParams.delete('foo');
  expect(url.toString()).to.equal('https://www.example.com/');
});

It adds an extra ? if no params present.

In [email protected]

String(new URLSearchParams(new URLSearchParams('?key=value')))
returns
value=key

In Chrome 63, If I run:

const test1 = new URLSearchParams('?a=1?b=2&c=3');
test1.get('a');

then I get 1?b=2

With this polyfill, I get 1?b.

Url-search-params-polyfill also mimicks the Chrome behavior.

If I try to create a new URL with the value "invalidUrl", instead of throwing an error it creates a new URL with the value appended to the current location (e.g. https://google.com/invalidUrl).

On other browsers (at least Chrome and Edge) it seems to work fine.

When using a form submit to search, forms encode spaces as +:

<form action="/search">
  <input type="hidden" name="q" value="hello world">
</form>
<!-- Submit results in URL: "<origin>/search?q=hello+world" -->

When decoding this URL and fetching the q parameter the result differs between browsers with and without polyfill:

// href => <origin>/search?q=hello+world
const url = new URL(location.href);
console.log(url.searchParams.get('q'));
// Prints "hello world" in latest Chrome
// Prints "hello+world" in Edge with this polyfill

I looked up how parameters with URLSearchParams should be handled, and it seems the search params should use form encoding:

1. Set should update entry list, and then do the update steps (whatwg)
2. The update steps should serialize all search params (whatwg)
3. Serialization uses the form encode serializer (whatwg)
4. The serialization above uses a byte serializer where spaces should be replaced by + for both search param name and values (whatwg)

In short, the steps for encoding that are listed on whatwg seems to follow encodeURIComponent() except for + which is encoded as %20. I suggest that a method that respects space as + to be followed for decoding and encoding search params and their values.

Hi, just want to mention that URLSearchParams.sort() is not implemented. MDN Link

Otherwise the polyfill works great!

Seems to be because Safari escapes the pathname set by url-polyfill.js#L173, causing the comparison (u.href === 'http://a/c%20d') to return false:

1. URLSearchParams MUST be reused (like in #9)
2. modification of url.search MUST modify searchParams

Example:

const u = new URL('http://example.org/?')
const sp = u.searchParams
console.log(sp === u.searchParams);

u.search = "x=1"
console.log(sp.get('x'))


sp.set('y', 1)

console.log(u.search)
sp.set('y', null);
console.log('' + sp)

Look at screenshot (left - native URL, right - polyfill)

Here's my example URL:
https://dash.local/Auth/o/authorize/?response_type=token&client_id=eC5Tuezee6eebahn5xo9moo4edai2weepheethah&redirect_uri=https://dash.local/Manager/oauth2-redirect&state=Manager

When I parse it in Chrome:

hash: ""
host: "dash.local"
hostname: "dash.local"
href: "https://dash.local/Auth/o/authorize/?response_type=token&client_id=eC5Tuezee6eebahn5xo9moo4edai2weepheethah&redirect_uri=https://dash.local/Manager/oauth2-redirect&state=Manager"
origin: "https://dash.local"
password: ""
pathname: "/Auth/o/authorize/"
port: ""
protocol: "https:"
search: "?response_type=token&client_id=eC5Tuezee6eebahn5xo9moo4edai2weepheethah&redirect_uri=https://dash.local/Manager/oauth2-redirect&state=Manager"
searchParams: URLSearchParams {}
username: ""
__proto__: URL

When I parse it in IE11 (that thing won't let me copy/paste...):

host, hostname, protocol are all missing.

What is the difference between this repo and @ungap/url-search-params ?

Probably not an intended target environment, but trying to instantiate a URL in nativescript results in an exception: ReferenceError: document is not defined.

It's not even an "ES7 specification", it's WHATWG: http://url.spec.whatwg.org

Please avoid false advertising.

on npm there are multiple version while on github there are only 2 version.

is it possible to update the release tags on github?

The baseURL-parameter passed to the constructor seems to be ignored when calculating the property values (e.g. origin) of the resulting URL object.

Two screenshots from the IE11 console to illustrate the problem

The first one shows the correct result, when creating an URL object without using a base-URL:

The second shows the empty properties when the same URL is created of from a base-URL:

When attempting to construct a URL using a relative path and a base argument matching the current document's window.location.href, an error TypeError: Invalid URL is thrown.

Environment: IE10
Steps to reproduce:

new URL("/my/path", window.location.href)

(in my test my path was http://timelord.local:4200/candidates;location=martin_pl;date=2019-12-24)