Problem/Motivation
Prior to #39, Drupal.AjaxCommands.prototype.insert() always added a DIV wrapper to the content returned by the server. Since #39, it only does that if the content isn't already contained in a single root element. The current HEAD code is:
// For legacy reasons, the effects processing code assumes that new_content
// consists of a single top-level element. Also, it has not been
// sufficiently tested whether attachBehaviors() can be successfully called
// with a context object that includes top-level text nodes. However, to
// give developers full control of the HTML appearing in the page, and to
// enable Ajax content to be inserted in places where DIV elements are not
// allowed (e.g., within TABLE, TR, and SPAN parents), we check if the new
// content satisfies the requirement of a single top-level element, and
// only use the container DIV created above when it doesn't. For more
// information, please see http://drupal.org/node/736066.
if (new_content.length !== 1 || new_content.get(0).nodeType !== 1) {
new_content = new_content_wrapped;
}
There are multiple conditions where even the more limited DIV wrapping creates problems (see comments #41-#48).
Proposed resolution
Figure out if we can improve ajax.js to never require the DIV wrapper. Specifically:
// For legacy reasons, the effects processing code assumes that new_content
// consists of a single top-level element.
Can we fix that?
// Also, it has not been
// sufficiently tested whether attachBehaviors() can be successfully called
// with a context object that includes top-level text nodes.
Can we test/fix that?
Remaining tasks
User interface changes
API changes
Original report by @peterpoe
As a workaround for a Safari bug, ajax.js wraps new content inside an empty div after a successful ajax request:
// Manually insert HTML into the jQuery object, using $() directly crashes
// Safari with long string lengths. http://dev.jquery.com/ticket/3178
var new_content = $('<div></div>').html(response.data);
The div makes inserting content not at block level (like in table rows and spans), difficult to achieve. I have published a workaround for Drupal 6 here: http://drupal.org/node/472328
Since the corresponding bug has been solved in Safari since 2009-03-19, I think that both Safari 3.2.3 and 4.x won't crash anymore with long strings. Given that Safari 3 has is used by 0.3% of web users, my opinion is that the limitations posed by the workaround are now worse than the problem solved.
Attached patch changes the behavior to:
var new_content = $(response.data);
