document.implementation.createHTMLDocument("")-created documents interpret the href property of anchor elements different in different browsers, e.g. in Chrome returning an empty string. This affects our jQuery.parseHTML. The createHTMLDocument usage has been backed out on 1.12-stable & 2.2-stable but we try to may make it work for 3.0.
In #2941 (comment) @gibson042 suggested to create a <base> element, setting it to the base of the current document.
The original issue: 2941
I'll just repeat my comment on the proposed fix:
@gibson042's fix looks like the correct way to go about it. Based on the brief look I had at the specs, the default base URL is about:blank, so if your intention is to make the behaviour match the document fallback then you'd need to set the base URL anyway, for all browsers. The way it's currently done by jQuery is technically incorrect. Even if the Chromium bug is fixed correctly, you'd still need to do this to match document behaviour.
Also, if this is going to be a permanent fix it'd probably be a good idea to make sure a <base> element does not already exist in the input.
Reviewing the patched parseHTML( data, context, keepScripts ), the thing that struck me was that the behavior varies a lot depending on whether context is provided. Since a constructor like $("<input>") passes document to the method by default, it circumvents any do-not-run-script benefit of the missing-context case. So if we want to make parseHTML() safer I'm wondering if we should try so hard to pass document for cases like that.
parseHTML( data, context, keepScripts )
Core: set the base href of the context in parseHTML