Verified this happens in all browsers on my machine: Firefox 18, Chrome 24, Safari 6.0.2. Both org.icefaces.diffConfig and Firefox Firebug Net tab corroborate that the transmitted DOM only includes one br tag. Further, there are no other br tags on the page at all. After the update, the inspector shows the two br tags. The body is being updated.

Tracing through the Mojarra 2.1.6 jsf.js execution for the body update process shows that the specific method used for copying the new body into the old body is responsible for the br duplication. There is no Mojarra bug, it's just that the DOM function used seems to have this bug in all browsers.

Here's the function call stack:

0790 var doUpdate = function doUpdate(element, context) {
...
0869 elementReplace(getBodyElement(newsrc), docBody);

0732 var elementReplace = function elementReplace(newElement, origElement) {
0733 copyChildNodes(newElement, origElement);

0607 var copyChildNodes = function copyChildNodes(nodeFrom, nodeTo) {
...
0625 nodeTo.appendChild(ownerDoc.importNode(nodes[i], true));

It looks like Element.appendChild(Document.importNode(...)) is causing the problem, since nodes[i] does not have the br tag duplication, but nodeTo then has it.

Wrapping the br in a div does not solve this.

With Mojarra, a regular element update goes through a completely different code path than a body update, so by constricting the DOM update to just within the body, through a simple app change, I was able to keep the br tag duplication from happening. I just inserted an h:panelGroup immediately within the body of both pages, and put everything that was in the body to be inside the h:panelGroup. I gave the h:panelGroup(s) in each page the same id, which makes our update mechanism treat them the same, and constrain the update to the h:panelGroup(s).

Won't fix, since not our bug, but is either a cross browser bug in Element.appendChild(Document.importNode(...)) or a Mojarra bug for using those methods. Simple panelGroup app work-around exists.

There is a possibility that the framework could automatically add a div in-between the body and the body contents, that would always use a consistent id, so that navigations would not trigger the body update, and apps would not need to manually do the work-around.