[
https://issues.apache.org/jira/browse/WICKET-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Retzlaff updated WICKET-3820:
---------------------------------
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.
was:
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?
(I haven't had a chance to test this.)
> 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
> 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
