Skip to content
This repository has been archived by the owner on Oct 8, 2021. It is now read-only.

Panel: not possible to bind to button toggling a panel #7301

Closed
frequent opened this issue Apr 8, 2014 · 5 comments
Closed

Panel: not possible to bind to button toggling a panel #7301

frequent opened this issue Apr 8, 2014 · 5 comments
Assignees
Milestone

Comments

@frequent
Copy link
Contributor

frequent commented Apr 8, 2014

Trying to bind to a button toggling a panel only works like this:

$(document).find(".action1").on("click", function() {
    alert("1");
});

The "normal" way,

$(document).on("click", ".action2", function () {
    alert("2")
});

does not trigger the alert.

JSBIN: here

Removing the JQM script tag will make both ways works as expected, so there must be something preventing the click to trigger courtesy of JQM.

The click is useful, for example to setting a pointer for content to display on click and loading the content on beforeOpen (works nicely with popups, so on panel, this is a bug to me)

@frequent
Copy link
Contributor Author

frequent commented Apr 8, 2014

Not sure this is a good practice fix, but removing the return false inside the panels _handleClick method would allow the click event to bubble up, while the preventDefault seems to prevent the browser from trying to make an Http request (on my latest FF).

_handleClick: function( e ) {
    var link,
      panelId = this.element.attr( "id" );

    if ( e.currentTarget.href.split( "#" )[ 1 ] === panelId && panelId !== undefined ) {

      e.preventDefault();
      link = $( e.target );
      if ( link.hasClass( "ui-btn" ) ) {
        link.addClass( $.mobile.activeBtnClass );
        this.element.one( "panelopen panelclose", function() {
          link.removeClass( $.mobile.activeBtnClass );
        });
      }
      this.toggle();
      //return false; -> Allow to bubble
    }
  },

@gabrielschulhof
Copy link

We need to figure out why we're not letting it bubble in the first place.

@gabrielschulhof
Copy link

OK. It looks like we're returning false in order to prevent the click routing from doing navigation. preventing default should suffice in this case.

@gabrielschulhof
Copy link

... because we've updated the click routing to not handle clicks for which the default has been prevented.

@frequent
Copy link
Contributor Author

frequent commented Apr 8, 2014

@gabrielschulhof : +1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants