Bug Tracker

#14846 closed bug (invalid)

Opened March 04, 2014 09:38PM UTC

Closed March 31, 2014 08:50AM UTC

$.buildFragment does not correctly include whitespace in IE8

Reported by: justinbmeyer@gmail.com Owned by: justinbmeyer@gmail.com
Priority: undecided Milestone: None
Component: unfiled Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:
Description

Here's a fiddle demonstrating the issue: http://jsfiddle.net/p6Way/1/. As JSFiddle doesn't work in IE8, you can open http://fiddle.jshell.net/p6Way/1/show/ to see the problem.

Essentially, text like: "<-\\n>" is not properly converted to a text node with the equivalent nodeValue in IE8.

A possible fix:

After setting the innerHTML here:

tmp.innerHTML = wrap[1] + elem.replace( rxhtmlTag, "<$1></$2>" ) + wrap[2];

Check if only one child node was created. If only a single childNode was created, there were no valid html tags. Therefore, simply create a text node with it's nodeValue as the elem.

An alternative would be to improve the rhtml regular expression to match HTML better.

I'm happy to submit a fix for this if this is something you are interested in fixing. Implementing the mustache spec depends on this character combination working.

Attachments (0)
Change History (5)

Changed March 04, 2014 10:21PM UTC by dmethvin comment:1

Is Mustache calling $.buildFragment directly? It's not a public API and might change. We did a lot of refactoring internally in the 1.9 timeframe for example.

To the point, though, that regex has been troublesome but implements a feature that we can't take out. At least your proposed fix doesn't require changing the regex.

Changed March 04, 2014 10:40PM UTC by anonymous comment:2

What feature does it implement (other than toggling between simply creating a text node or using the .innerHTML trick)?

I'm currently patching $.buildFragment like:

var text = "<-\\n>";
var frag = $.buildFragment([text], document);
if(text !== frag.childNodes[0].nodeValue) {
	
	var oldBuildFragment  = $.buildFragment;
	$.buildFragment = function(content, context){
		var res = oldBuildFragment(content, context);
		if(res.childNodes.length === 1 && res.childNodes[0].nodeType === 3) {
			res.childNodes[0].nodeValue = content[0];
		} 
		return res;
	}
}

This way, only browsers that get things wrong are affected.

In regards to non-public APIs ... Afaik, there's not a great and as fast alternative that jQuery provides. We have a computability layer so if the API changes, we will update things accordingly.

We actually "feature detect" how $.fn.domManip is called and hook into it differently depending on which version of jQuery we are running against.

Changed March 05, 2014 05:57PM UTC by gibson042 comment:3

The proposed approach will fail when the HTML-resembling text is buried in a string of actual HTML (e.g., jQuery.html("<div><-\\n></div>")). This looks to me like another use case for #14228.

Also, out of curiosity: why not HTML-escape or CDATA-wrap the problematic text characters? Is https://github.com/mustache/spec/blob/v1.1.2/specs/~lambdas.yml#L100 in particular the source of your problem?

Changed March 16, 2014 04:01PM UTC by dmethvin comment:4

owner: → justinbmeyer@gmail.com
status: new → pending

Let's keep the discussion going on this, if needed.

Changed March 31, 2014 08:50AM UTC by trac-o-bot comment:5

resolution: → invalid
status: pending → closed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!