Ticket #9530 (closed bug: duplicate)
jQuery erroneously treats some a tags as self-closing
| Reported by: | contact@… | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | manipulation | Version: | 1.6 |
| Keywords: | Cc: | ||
| Blocking: | Blocked by: |
Description
Test case:
Compare http://jsfiddle.net/npMDu/1/
to: http://dl.dropbox.com/u/105727/web/why_not_links.html
Same exact input, different outputs.
What’s going on:
Sometimes you have code like:
<a href=http://example.com/>foo</a>
For example, one HTML sanitizes stripped out the surrounding quotes on the attribute value and gave me that output.
If you do an .html(foo) where foo is the above, then jQuery parses this as
if it were <a href="http://example.com" />, self-closing, that is, <a href="http://example.com/..."></a>foo</a>
Thus the link is not actually clickable anymore; it's empty and then followed by a text node and an extra closing tag.
Change History
comment:2 Changed 2 years ago by anonymous
I realize the problem description is a bit sparse, but basically: markup rendered directly in an HTML document (in WebKit) ≠ the same markup placed into a document via jQuery.
comment:3 Changed 2 years ago by anonymous
Simpler test case: http://jsfiddle.net/npMDu/3/
comment:4 Changed 2 years ago by rwaldron
- Priority changed from undecided to low
- Resolution set to invalid
- Status changed from new to closed
- Component changed from unfiled to manipulation
Your html is invalid. When using unquoted attribute syntax, the "/" (solidus) is being seen as a closing of the anchor. If you A) remove the solidus or B) add a space between the solidus and the closing greater-than, this issue does not exist.
comment:5 Changed 2 years ago by anonymous
Please re-open this issue.
According to http://html5.validator.nu/ the markup I used above is valid.
Furthermore all the browsers I checked render it as expected. Only jQuery misunderstands.
While it is true that using quotes or inserting a space would “solve” the problem, note that I am not generating the input HTML by hand! It is html5lib that is outputting this markup. ( https://code.google.com/p/html5lib/)
Please-reopen for discussion, as this is indeed a bug.
comment:6 Changed 2 years ago by anonymous
Please note that .innerHTML and .html() yield very different results here, which is not intuitive and backs my claim that this is indeed a real bug.
New fiddle to demonstrate: http://jsfiddle.net/alanhogan/Neznc/6/
comment:7 Changed 2 years ago by rwaldron
- Status changed from closed to reopened
- Resolution invalid deleted
comment:8 Changed 2 years ago by anonymous
Note that I repeated my tests on these URLs:
http://jsfiddle.net/alanhogan/Neznc/6/
and
http://dl.dropbox.com/u/105727/web/why_not_links.html
in IE7, IE8, and Firefox (originally tested in Chrome), and the behavior is consistent: .innerHTML and native web page rendering get it right, and jQuery .html interprets erroneously as a self-closing element.
comment:9 Changed 2 years ago by anonymous
Uh, interestingly enough, the last linked jsfiddle gains an odd quirk in the latest stable Chrome: the second button may not appear to remove the link! I think a redraw is failing to fire, as resizing the window or clicking the first button causes the text to finally disappear, and attempting to select or click the link, while it’s visible but removed, will fail. Separate issue, please ignore (or use Safari/Firefox if confused).
comment:10 Changed 2 years ago by rwaldron
Yeah I saw that. It's still pretty easy to avoid by quoting the href attribute value.
comment:11 Changed 2 years ago by dmethvin
I don't think this is something we can fix in the general case; IE6/7/8 also interprets a trailing slash in a url as a self-closing tag. (See #8939.) Is it such a burden to quote the attribute? If your HTML is being built from a variable you will need to be doing escaping anyway, right?
comment:12 Changed 2 years ago by anonymous
I’m not sure I get what’s happening in #8939, but I tested IE8 in IE8 and IE7 modes and it parses the A tag correctly, that is to say, not like jQuery does, but like all other browsers.
comment:13 Changed 2 years ago by anonymous
I am not building the URL from a variable, but rather, my HTML sanitizer is actually removing unnecessary quotes. And in all cases but jQuery’s, the quotes would indeed be unnecessary here.
I disagree with the parser’s behavior and am looking into changing it, but this bug is (a) still valid IMO and (b) something that, if fixed, would also solve my issue.
comment:14 Changed 2 years ago by anonymous
Relevant html5lib "discussion" (no replies yet): http://groups.google.com/group/html5lib-discuss/browse_thread/thread/6d80ebe39e1f688b
The issue arises because of a combination of html5lib and jQuery quirks.
Disheartening to see that neither library seems to acknowledge a problem yet.
In the meantime, using raw .innerHTML solves my issue for now.
comment:16 Changed 23 months ago by rwaldron
- Status changed from open to closed
- Resolution set to duplicate
comment:17 Changed 23 months ago by rwaldron
Duplicate of #6236.
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

Of note: the last line in my Fiddle, above, shows how the text is no longer considered part of the A tags!