ICEfaces
  1. ICEfaces
  2. ICE-10261

ace:accordion, can't update active index programmatically

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.3
    • Fix Version/s: 4.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Any
    • Assignee Priority:
      P1

      Description

      It's not possible to update the active index of an ace:accordion unless it's by direct interaction with the component or programmatically only at initialization time. So, it's not possible to update the active index through an external control or by applying some custom logic. The new showcase app shows this issue, where the search box doesn't cause the accordion to be opened where the selected demo is located.

        Activity

        Hide
        Arturo Zambrano added a comment -

        r4260: committed fix to allow updating the active index programmatically.

        Since the hidden input that contains the active index has its own client id, it was being updated by itself without reinitializing the component. However, a dynamic script was added to only set the new tab index in the jQuery widget, in order to avoid re-creating the entire component.

        Show
        Arturo Zambrano added a comment - r4260: committed fix to allow updating the active index programmatically. Since the hidden input that contains the active index has its own client id, it was being updated by itself without reinitializing the component. However, a dynamic script was added to only set the new tab index in the jQuery widget, in order to avoid re-creating the entire component.
        Hide
        Liana Munroe added a comment -

        Tested with ICEfaces 4 r42615, Tomcat 7 and all browsers.
        Using Chrome and IE 11, the accordion does get opened after selecting a demo from the search field but not on the first attempt. Second and subsequent attempts will go to the proper accordion panel. The first attempt leaves the ACE Overview accordion panel selected. Occasionally FF will open the relevant panel the first time through.

        Show
        Liana Munroe added a comment - Tested with ICEfaces 4 r42615, Tomcat 7 and all browsers. Using Chrome and IE 11, the accordion does get opened after selecting a demo from the search field but not on the first attempt. Second and subsequent attempts will go to the proper accordion panel. The first attempt leaves the ACE Overview accordion panel selected. Occasionally FF will open the relevant panel the first time through.
        Hide
        Liana Munroe added a comment -

        Verified resolved ICEfaces 4 trunk r42629. Tomcat 7 , FF 31, Chrome 37, IE 11.

        Show
        Liana Munroe added a comment - Verified resolved ICEfaces 4 trunk r42629. Tomcat 7 , FF 31, Chrome 37, IE 11.
        Hide
        Ken Fyten added a comment -

        Re-opening as the original fix was backed out to resolve ICE-10266.

        Show
        Ken Fyten added a comment - Re-opening as the original fix was backed out to resolve ICE-10266.
        Hide
        Arturo Zambrano added a comment -

        I found out the reason why a request was being made when updating the active index in the accordion component. In the jQuery UI code, changing the active index programmatically also triggers the 'accordionchangestart' event, which is the one we use to attach our own event handler to make a request to the server after clicking on an accordion pane. So the solution for ICE-10261 would consist in finding a way to expand the corresponding accordion pane, without triggering any event.

        Show
        Arturo Zambrano added a comment - I found out the reason why a request was being made when updating the active index in the accordion component. In the jQuery UI code, changing the active index programmatically also triggers the 'accordionchangestart' event, which is the one we use to attach our own event handler to make a request to the server after clicking on an accordion pane. So the solution for ICE-10261 would consist in finding a way to expand the corresponding accordion pane, without triggering any event.
        Hide
        Arturo Zambrano added a comment -

        Committed new fix at revision 42643. The fix consists in modifying the jQuery UI code to add an 'activeNoEvent' option to the Accordion widget to allow activating an accordion pane without triggering the 'changestart' event (which caused sending an additional request) and without focusing on the pane header (which caused the page to scroll down).

        Show
        Arturo Zambrano added a comment - Committed new fix at revision 42643. The fix consists in modifying the jQuery UI code to add an 'activeNoEvent' option to the Accordion widget to allow activating an accordion pane without triggering the 'changestart' event (which caused sending an additional request) and without focusing on the pane header (which caused the page to scroll down).
        Hide
        Carmen Cristurean added a comment -

        Rev. 42651/ testing in FF31, Chrome37, IE10
        showcase > Overview demo does not work properly in FF31/Chrome37 (tabs cannot be opened up after collapsing the accordion panes).

        Steps:
        Initially when coming to this demo, all tab panes are closed.

        • click Tab1 to open it -> Tab1 opened.
        • click Tab1 to close it -> Tab1 closed, but Tab3 opens up.
        • click Tab3 to close it -> Tab3 closed.
        • all tabs are closed now; from now on, when clicking on any tab pane, they open up but then immediately close back.
          This is not an issue in IE10.
        Show
        Carmen Cristurean added a comment - Rev. 42651/ testing in FF31, Chrome37, IE10 showcase > Overview demo does not work properly in FF31/Chrome37 (tabs cannot be opened up after collapsing the accordion panes). Steps: Initially when coming to this demo, all tab panes are closed. click Tab1 to open it -> Tab1 opened. click Tab1 to close it -> Tab1 closed, but Tab3 opens up. click Tab3 to close it -> Tab3 closed. all tabs are closed now; from now on, when clicking on any tab pane, they open up but then immediately close back. This is not an issue in IE10.
        Hide
        Arturo Zambrano added a comment -

        r42654: fix to avoid processing setActiveIndex(), when the index is the same as the state holder, in order to avoid closing tabs in collapsible accordions; fix to convert an active index of '-1' to 'false' in the client side, since that's how the jQuery Accordion widget understands that all panels should be collapsed.

        Show
        Arturo Zambrano added a comment - r42654: fix to avoid processing setActiveIndex(), when the index is the same as the state holder, in order to avoid closing tabs in collapsible accordions; fix to convert an active index of '-1' to 'false' in the client side, since that's how the jQuery Accordion widget understands that all panels should be collapsed.
        Hide
        Carmen Cristurean added a comment -

        R. 42654:
        ace:accordion > Overview: if checking a checkbox in Tab1, and then closing Tab1, none of the panes can be re-opened; this occurs in all browsers (tested in IE10,11; FF31, Chrome37), however in Chrome I did not always reproduce this issue.

        Show
        Carmen Cristurean added a comment - R. 42654: ace:accordion > Overview: if checking a checkbox in Tab1, and then closing Tab1, none of the panes can be re-opened; this occurs in all browsers (tested in IE10,11; FF31, Chrome37), however in Chrome I did not always reproduce this issue.
        Hide
        Arturo Zambrano added a comment -

        r42656: fix to consult the active index from the internal state of the jQuery UI Accordion widget object when determining whether to process setActiveIndex() or not.

        Show
        Arturo Zambrano added a comment - r42656: fix to consult the active index from the internal state of the jQuery UI Accordion widget object when determining whether to process setActiveIndex() or not.
        Hide
        Arturo Zambrano added a comment -

        r42659: Committed various fixes to support all use cases. This also solves the issue reported in ICE-10266 with the CSS source accordions in 'required styling' demos.

        Show
        Arturo Zambrano added a comment - r42659: Committed various fixes to support all use cases. This also solves the issue reported in ICE-10266 with the CSS source accordions in 'required styling' demos.
        Hide
        Carmen Cristurean added a comment - - edited

        R. 42661/ IE10, IE11, Chrome37, FF31: re-tested showcase > accordion demos, and no issues have been found.
        Also, the CSS Source view issue is resolved.

        Show
        Carmen Cristurean added a comment - - edited R. 42661/ IE10, IE11, Chrome37, FF31: re-tested showcase > accordion demos, and no issues have been found. Also, the CSS Source view issue is resolved.
        Hide
        Arturo Zambrano added a comment -

        r42670: Committed code that was meant to be committed previously. The last reported issue is now fixed.

        Show
        Arturo Zambrano added a comment - r42670: Committed code that was meant to be committed previously. The last reported issue is now fixed.
        Hide
        Liana Munroe added a comment - - edited

        ICEfaces 4 trunk r42671
        Tomcat 7, all browsers.
        Reopening because the QA accordion in ui:Repeat inside h:dataTable test is now failing. When selecting an inactive pane, the matching panes in the ui:repeat also become selected.
        This issue does not occur when accordion is alone inside ui:repeat, or h:dataTable or ace:dataTable.
        To reproduce:
        Use test app located at http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/accordion.
        Navigate to Accordion in Repeat and Data table test.
        In the first row, select an inactive pane.
        Note that all matching panes in the same row become activated.

        Show
        Liana Munroe added a comment - - edited ICEfaces 4 trunk r42671 Tomcat 7, all browsers. Reopening because the QA accordion in ui:Repeat inside h:dataTable test is now failing. When selecting an inactive pane, the matching panes in the ui:repeat also become selected. This issue does not occur when accordion is alone inside ui:repeat, or h:dataTable or ace:dataTable. To reproduce: Use test app located at http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/accordion . Navigate to Accordion in Repeat and Data table test. In the first row, select an inactive pane. Note that all matching panes in the same row become activated.
        Hide
        Arturo Zambrano added a comment - - edited

        The problem is with the test page/app itself. It just wasn't visible before, because before this fix there was no script to expand the active index dynamically, but all the hidden input fields, holding the active index for each accordion, were being updated. There was just no visible clue that there was something wrong with the app. Another way to see it, is to replace the accordion component on the test page (accordionRepeatDataTbl.xhtml) for an ace:tabSet, as in the following markup:

        <ace:tabSet id="accordion" clientSide="false" selectedIndex="#{accordion.activeIndex}">
        	<ace:tabPane id="cPane" label="Calgary">
        		<h:outputText id="outputTxt1" value="Calgary content"/>
        	</ace:tabPane>
        	<ace:tabPane id="vPane" label="Vancouver">
        		<h:outputText id="outputTxt2" value="Vancouver content"/>
        	</ace:tabPane>
        	<ace:tabPane id="tPane" label="Toronto">
        		<h:outputText id="outputTxt3" value="Toronto content"/>
        	</ace:tabPane>
        	<ace:ajax event="serverSideTabChange" />
        </ace:tabSet>
        

        The issue with the test page is also visible when using an ace:tabSet. The problem is that the activeIndex/selectedIndex is being bound to the 'accordion' variable, which is the variable declared in the outer h:dataTable, and not the variable declared in the inner ui:repeat. There's not even a variable declared in ui:repeat. So, all accordions inside ui:repeat are bound to the same outer variable, so when an active index is modified, all accordions bound to that property also have to update their active indexes. Also, the data collection is exactly the same for the h:dataTable and for the ui:repeat (accordionRepeatDataTblBean.accordions), which doesn't make much sense to me, but I'm not sure what was the original purpose of this test page. What I'm used to see with nested iterative containers is that there's a data object for for the outer container and a different data object for the inner container, each with their own variables. A similar test in the ace:tabSet test app follows this pattern. Please review this test page/app and make the necessary changes for it to work normally.

        Show
        Arturo Zambrano added a comment - - edited The problem is with the test page/app itself. It just wasn't visible before, because before this fix there was no script to expand the active index dynamically, but all the hidden input fields, holding the active index for each accordion, were being updated. There was just no visible clue that there was something wrong with the app. Another way to see it, is to replace the accordion component on the test page (accordionRepeatDataTbl.xhtml) for an ace:tabSet, as in the following markup: <ace:tabSet id= "accordion" clientSide= "false" selectedIndex= "#{accordion.activeIndex}" > <ace:tabPane id= "cPane" label= "Calgary" > <h:outputText id= "outputTxt1" value= "Calgary content" /> </ace:tabPane> <ace:tabPane id= "vPane" label= "Vancouver" > <h:outputText id= "outputTxt2" value= "Vancouver content" /> </ace:tabPane> <ace:tabPane id= "tPane" label= "Toronto" > <h:outputText id= "outputTxt3" value= "Toronto content" /> </ace:tabPane> <ace:ajax event= "serverSideTabChange" /> </ace:tabSet> The issue with the test page is also visible when using an ace:tabSet. The problem is that the activeIndex/selectedIndex is being bound to the 'accordion' variable, which is the variable declared in the outer h:dataTable, and not the variable declared in the inner ui:repeat. There's not even a variable declared in ui:repeat. So, all accordions inside ui:repeat are bound to the same outer variable, so when an active index is modified, all accordions bound to that property also have to update their active indexes. Also, the data collection is exactly the same for the h:dataTable and for the ui:repeat (accordionRepeatDataTblBean.accordions), which doesn't make much sense to me, but I'm not sure what was the original purpose of this test page. What I'm used to see with nested iterative containers is that there's a data object for for the outer container and a different data object for the inner container, each with their own variables. A similar test in the ace:tabSet test app follows this pattern. Please review this test page/app and make the necessary changes for it to work normally.
        Hide
        Liana Munroe added a comment -

        The QA test application has been updated as required and committed to http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/accordion r39540. No issues are present.

        Show
        Liana Munroe added a comment - The QA test application has been updated as required and committed to http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/accordion r39540. No issues are present.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: