Panel: Opening from anchor tag within listview does not remove active button class

[tschettler]

Opening a panel using an anchor tag within a list view does not remove the ui-btn-active class from the li containing the anchor.

Test Page: http://jsbin.com/idabam/2

Actual outcome: The "Open Panel" list item retains an active state.

Platforms/browsers tested:

• iPhone 4 (Mobile Safari)
• Android

jQuery Mobile 1.3.1
jQuery 1.9.1

This should work similar to how the popup widget handles removing the active class. Adding a delay before the active class is removed would also be a helpful UI cue.

Would a change similar to the following work?

_bindLinkListeners: function() {
    var self = this;

    self._page.on( "click.panel" , "a", function( e ) {
        if ( this.href.split( "#" )[ 1 ] === self._panelID && self._panelID !== undefined ) {
            e.preventDefault();
            var $link = $( this );
            if ( ! $link.hasClass( "ui-link" ) ) {
                $link.addClass( $.mobile.activeBtnClass );
                self.element.one( "panelopen panelclose", function() {
                    //remove after delay
                    setTimeout( function() {
                        $link.closest('li.' + $.mobile.activeBtnClass).andSelf().removeClass( $.mobile.activeBtnClass );
                    }, 300);
                });
            }
            self.toggle();
            return false;
        }
    });
},

[jaspermdegroot]

@tschettler

Thanks for reporting the issue.

For 1.4 we are working on reducing the markup we generate for buttons, including the ones in listviews. As a result the anchor element in the list item will get the button classes, including the active state class. This resolves this issue.
It also means we can remove the code that was added (cb54f03) to fix the same issue we had with popups (#4611).

The ui-btn-active class is removed when the process of opening the panel is finished, so there is no need to use a timeout here.
The 300ms timeout we use in the popup widget was not part of the fix for #4611, but was added earlier (e612aa8). I am not completely sure why we choose to use a timeout.
@gabrielschulhof can't we remove the active state class on popupafteropen?

[jaspermdegroot]

I just realized that we should fix this for 1.3.2. I will apply the same fix as we did for popups.