Details
Description
Chrome 13.0.782.24 beta changes the way "element.outerHTML = text" is handled in a way that breaks Wicket's AJAX rendering compared to Chrome 12.0.782.100 (stable).
Before the outerHTML assignment that replaces the DOM content, Wicket.replaceOuterHtmlSafari() grabs element.nextSibling. After the outerHTML assignment, it iterates through the new element siblings until the previous "next" is encountered. However, when the new text contains trailing whitespace, and the "previous next" is a text node, the new version of Chrome merges the two text nodes into a single text node, invalidating the iteration's termination condition. This eventually leads to a null reference, breaking subsequent Javascript/AJAX functionality.
Is it a good idea to simply add "while (next.nodeType == 3) next = next.nextSibling;" after the next assignment in Wicket.replaceOuterHtmlSafari? This just makes the "previous next" reference something other than a text node.
Attachments
Attachments
Issue Links
- is duplicated by
-
WICKET-3943 Wicket.replaceOuterHtmlSafari broken in safari 5.1
-
- Resolved
-
-
WICKET-3985 Ajax calls does not support IPad Safari
-
- Resolved
-