New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$.parseHTML() creates anchor elements with empty href property in Chrome #2965

Closed
mgol opened this Issue Mar 2, 2016 · 2 comments

Comments

Projects
None yet
4 participants
@mgol
Member

mgol commented Mar 2, 2016

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

@BobVul

This comment has been minimized.

Show comment
Hide comment
@BobVul

BobVul Mar 2, 2016

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.

BobVul commented Mar 2, 2016

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.

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Mar 2, 2016

Member

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.

Member

dmethvin commented Mar 2, 2016

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.

@timmywil timmywil self-assigned this Mar 21, 2016

timmywil added a commit to timmywil/jquery that referenced this issue Mar 28, 2016

@timmywil timmywil closed this in 10fc590 Apr 4, 2016

@lock lock bot locked as resolved and limited conversation to collaborators Jun 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.