Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#6905 closed bug (notabug)

Accordion does not always open the specified pane when initialized

Reported by: coreyo Owned by:
Priority: minor Milestone: 1.9.0
Component: ui.accordion Version: 1.8.9
Keywords: Cc:
Blocked by: Blocking:

Description

Supplying a valid pane index with the "active" option does not always work properly. Likewise, setting the 'active' option with a later script seems to hold equally buggy results.

I am sorry that I cannot post explicit code as my work requires a bit of non-disclosure, however I will try to provide as much information as I can.

I have an asp.net page with form controls in my accordion content. The forms do regular postbacks as different inputs are changed. As a way of saving the accordion state, I attached a function to save the index of the open pane to a hidden form element. Every time the pane index changes, it updates the value of the hidden form, which then gets passed back to the accordion at every postback.

The initial page load gives a hidden field that looks something like this:

<asp:HiddenField id="AccordionIndex" Value="0" runat="server">

In the header, I have the following:

<link type="text/css" href="css/ui-lightness/jquery-ui.css" rel="Stylesheet" />
<script type="text/javascript" src="scripts/jquery.js"></script>
<script type="text/javascript" src="jquery-ui.js"></script>
<script type="text/javascript">
    .noConflict();
    jQuery(document).ready(function($) {

        $('#accordion').accordion({
            collapsible: true;
            autoHeight: false;
            navigation: true;
            active: <%= this.AccordionIndex.Value %>,
            header: 'h3'
        }).bind( 'accordionchange', function(event, ui) {
            document.getElementById('<%= this.AccordionIndex.ClientID %>'.value = $('#accordion').accordion( 'option', 'active' );
        });

    )};
</script>

After doing some relatively exhaustive testing, I was able to determine that the onchange event was updating the hidden field properly, which was correctly set at each postback. In addition, I was able to determine that the option passed upon initialization was also correct, without quotes, and looked proper syntactically. However, the accordion would randomly open up to the last pane upon initialization, regardless of the option passed to it.

I engineered a hack, called right after the initialization in an attempt to combat this problem:

var accordionIndex = document.getElementById('<%= this.AccordionIndex.ClientID %>').value;
if (accordionIndex == "false") {
    $('#accordion').accordion( 'option', 'active', false );
}
else {
    $('#accordion').accordion( 'option', 'active', parseInt(accordionIndex));
}

In version 1.8.8, this fixed this particular problem (though it should have been unnecessary).

The original problem has persisted in version 1.8.9, and the last pane (pane 2) randomly opens on the page load, contrary to the option that it has been passed on initialization.

However, my hack is causing a new side-effect. Now, when the page is first initialized, the first accordion pane is rendered as open, but then immediately slides shut. The initialization code passing it an index of 0, as well as the hack firing an event to set active pane to 0 should both be redundant, however it seems that the second call to make pane 0 active is actually closing it.

would appreciate a fix.

Change History (3)

comment:1 Changed 10 years ago by Scott González

Resolution: invalid
Status: newclosed

Your code is invalid as you're using semicolons instead of commas. Also, you shouldn't use the navigation option in conjunction with the active option.

comment:2 in reply to:  1 Changed 10 years ago by coreyo

Replying to scott.gonzalez:

Your code is invalid as you're using semicolons instead of commas. Also, you shouldn't use the navigation option in conjunction with the active option.

Apologies on the semicolons. All code was fatfingered in, not pasted, and code is correct in the actual source. I must have missed that in my proofread.

As for the navigation option, that seems to have been the problem. Working without the option seems to fix the behavior and remove the need for my extra hack. It seems that the actual state restore from the navigation option can happen at an unexpected point later in the page load cycle.

I guess I'd change the title of this ticket to "Default value for 'navigationFilter' yields unpredictable results. Using "navigation" and "active" options together not advisable. Further explanation in documentation might be a good idea."

Last edited 10 years ago by coreyo (previous) (diff)

comment:3 Changed 10 years ago by Scott González

The navigation options are deprecated and have already been removed from the core of the plugin in master.

Note: See TracTickets for help on using tickets.