[
https://issues.apache.org/jira/browse/WICKET-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-3820.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.5-RC6
1.4.18
Assignee: Martin Grigorov
> New Chrome merges text in replaceOuterHtml, breaking wicket-ajax
> ----------------------------------------------------------------
>
> Key: WICKET-3820
> URL: https://issues.apache.org/jira/browse/WICKET-3820
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.4.17, 1.5-RC5.1
> Environment: Chrome 13.0.782.24
> Reporter: Dan Retzlaff
> Assignee: Martin Grigorov
> Fix For: 1.4.18, 1.5-RC6
>
> Attachments: chromeajax.patch, chromeajax.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
