ICEfaces
  1. ICEfaces
  2. ICE-7546

ace:accordion inside ace:tabSet issue

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.RC1
    • Fix Version/s: 3.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Icefaces3/trunk revision 26767
      Browsers: IE8, Chrome 15
      Server: Tomcat6
    • Assignee Priority:
      P1

      Description

      The ace:accordion component inside ace:tabSet does not work properly: if switching to the closed panes, the accordion collapses altogether and panes cannot be open afterwards.
      This issue occurs in IE 8 and Chrome 15 (not in Firefox).

      Note: The accordion component on the test page was defined with collapsible="false".

      To reproduce:
      - test application location: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/accordion
      - load the test page for accordion isnide ace:tabSet: http://localhost:8080/accordion/accordionIceTabSet.jsf
      - page opens with first pane open. Click on the next pane to open -> this works fine.
      - click on the third pane -> this collapses all accordionPanes.

        Activity

        Hide
        Carmen Cristurean added a comment -

        The issue is still present with code revision # 27179 in IE8, Chrome15.

        Show
        Carmen Cristurean added a comment - The issue is still present with code revision # 27179 in IE8, Chrome15.
        Hide
        Arturo Zambrano added a comment -

        Fixed at revision 27193.

        The problem only occurred with autoHeight=true, which is the default. In this case jQuery UI, explicitly sets the heights of the panes. When the accordion is inside a tabPanel, it is created when the markup is still in the safe ids area, so it uses maxHeight = 0. This was fixed by adding code to re-calculate heights shortly after the accordion is created.

        Also, a minor issue when using dynamic=true was fixed. The content was being loaded directly in the root div of the pane, while it should be loaded inside the inner div with the id that ends with '_content'.

        Show
        Arturo Zambrano added a comment - Fixed at revision 27193. The problem only occurred with autoHeight=true, which is the default. In this case jQuery UI, explicitly sets the heights of the panes. When the accordion is inside a tabPanel, it is created when the markup is still in the safe ids area, so it uses maxHeight = 0. This was fixed by adding code to re-calculate heights shortly after the accordion is created. Also, a minor issue when using dynamic=true was fixed. The content was being loaded directly in the root div of the pane, while it should be loaded inside the inner div with the id that ends with '_content'.
        Hide
        Arturo Zambrano added a comment -

        I tried an alternative approach to avoid using a timeout. It consisted in modifying the jQuery code to avoid explicitly setting the heights when the panel has a height of zero and just ignore the autoHeight option. This didn't work however, because the very algorithm that calculates the heights of the panes needs to set the heights of the container nodes to "" (empty string), in order to obtain the height calculated by the browser. In all cases, this height is always zero and the result is the same. So, the timeout approach will stay until there's better mechanism to detect when a component has been moved from the safe id area to the actual pane in the tab set.

        Show
        Arturo Zambrano added a comment - I tried an alternative approach to avoid using a timeout. It consisted in modifying the jQuery code to avoid explicitly setting the heights when the panel has a height of zero and just ignore the autoHeight option. This didn't work however, because the very algorithm that calculates the heights of the panes needs to set the heights of the container nodes to "" (empty string), in order to obtain the height calculated by the browser. In all cases, this height is always zero and the result is the same. So, the timeout approach will stay until there's better mechanism to detect when a component has been moved from the safe id area to the actual pane in the tab set.
        Hide
        Carmen Cristurean added a comment -

        Verified fix with revision 27312 in IE8, Chrome16, Firefox 3.6.

        Show
        Carmen Cristurean added a comment - Verified fix with revision 27312 in IE8, Chrome16, Firefox 3.6.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Carmen Cristurean
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: