Will you accept a patch that uses new URL instead (where available)?

So nice to see this disapear! \o/

@jaubourg - were you responding to my question? :) If so, is that a yes?

@phistuck, I was just sharing my happiness regarding the disappearance of the regexp. Using the URL API is a good idea though but we'd probably need to wait for all supported browsers to implement it (I haven't checked if they all do right now). The general consensus is to avoid multiple code paths, especially for small, non-critical, parts of the code like this one.

@jaubourg - AJAX is used very frequently and the cost of creating an element in terms of memory (and possible garbage collection issues in the engine) is pretty big, compared to the URL constructor. Looks like everyone but Internet Explorer supports it.
Since the interface should be identical to the one <a> exposes (there share the interface), it should be a small change ($.isFunction(window.URL) ? new URL() : document.createElement("a")).

Well, this piece code is only executed once, not at each request. I agree it's a small change but I fail to see how critical it is. It seems rather logical to just wait for our support grid to only contain browsers that implement the URL object before simply switching to it.

I don't speak for the team though but that's my take on it.

During review of #1880 we discussed this but my take at the time was that it wasn't critical. Creating a link element a few times a second shouldn't be a perf or memory problem should it?

My bad, I hadn't scrolled enough to see it used in the ajax code proper :/

Still, I agree with Dave, perf is not an issue here.

Performance (in terms of speed) is less of an issue, but memory usage and failing to free the memory (the old Internet Explorer bug, for example) are concerning. Creating an element is a pretty big hammer and if you can avoid it with exactly the same interface, I do not see why not.

(But I understand your reasoning as well)

Are you saying there's a memory leak that new URL() would fix here?

I am not saying that there is one now (I have not checked it). I just say that an element is a big hammer that is better used sparingly when you have other options and I mentioned that browsers did use to have problems with element references and leaks. new URL is much more lightweight (and is the preferred way) than constructing <a>.
Developers used to create a whole new document for resolving URL components, for example, which is an even bigger hammer that new URL also replaces.

If new URL() worked everywhere there would be a better case for changing this, but as it is I'm not seeing any concrete problem here that requires a change.

Since the interface should be identical to the one exposes (there share the interface), it should be a small change ($.isFunction(window.URL) ? new URL() : document.createElement("a")).

It should but may not be. If there was a provable issue here I think we'd be more likely to change the code.