ICEfaces
  1. ICEfaces
  2. ICE-8928

ice:panelGrid generates extra line break tag upon navigation

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 3.2, EE-3.2.0.BETA
    • Fix Version/s: 4.0.BETA, 4.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Tomcat, Chrome, Firefox, IE9
    • Assignee Priority:
      P2
    • Salesforce Case Reference:
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      An extra tag is not generated if navigation occur to another page via <redirect/>

      Or, insert a panelGroup between the body and all other tags that are inside the body, in both pages, both using the same id, to constrain the update to the panelGroups instead of the body, so that Mojarra won't use the buggy browser DOM technique of Element.appendChild(Document.importNode(...)).
      Show
      An extra tag is not generated if navigation occur to another page via <redirect/> Or, insert a panelGroup between the body and all other tags that are inside the body, in both pages, both using the same id, to constrain the update to the panelGroups instead of the body, so that Mojarra won't use the buggy browser DOM technique of Element.appendChild(Document.importNode(...)).

      Description

      ice:panelGrid generates an extra line break tag upon non redirect navigation which in some cases may interfere or break page layouts.

      To reproduce:
      1. Use attached source code and deploy application.
      2. Open welcomeICEfaces page and click on Submit button to navigate
      3. Inspect generated HTML for ice:panelGrid.

        Issue Links

          Activity

          Hide
          Mark Collette added a comment -

          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.

          Show
          Mark Collette added a comment - 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.
          Hide
          Mark Collette added a comment -

          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.

          Show
          Mark Collette added a comment - 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.
          Hide
          Mark Collette added a comment - - edited

          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).

          Show
          Mark Collette added a comment - - edited 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).

            People

            • Assignee:
              Ken Fyten
              Reporter:
              Evgheni Sadovoi
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: