Yep, this is probably the same problem I ran into a while ago. I build a jQuery plug-in to deal with these types of issues when Prototype and jQuery coexist. It's called "jquery-prototype-custom-event-bridge", and can be found at https://github.com/Widen/jquery-prototype-custom-event-bridge.
After closely looking at the TB collapse javascript code, and then examining jQuery's trigger function implementation I realized that jQuery, when processing an event, attempts to execute a matching function on the DOM element if one exists and if preventDefault is not set on the event. Prototype adds a bunch of functions to each DOM element, and some of these match jQuery event types. Take the hide event, for example. If you trigger hide on an element, jQuery will execute Prototype's hide() function on the element. This presents a problem when a library, such as Twitter Bootstrap, uses a transition style to animate hiding an element. When the hide() function, added by Prototype, is called on the Element during handling of a hide event, the element is hidden at once. Of course this means that the transition never occurs. In some browsers (at least webkit), this means that the appropriate transitionend (webkitTransitionEnd for webkit UAs) event is never triggered. TB's resets some internal state when this event is triggered. Since, in this scenario, the event is never triggered in webkit browsers, TB thinks the element is still in the "transitioning" phase when an attempt is made to show the element again using a transition. This issue explains why hide actions (such as hiding/dismissing the overlay & the nav bar) happen immediately in some projects, without transitions. In the case of the (mobile) collapsible nav bar, it puts it into a state where the nav bar cannot be re-displayed after collapsing it once. Since TB thinks it is still in the transition phase, it ignores the request to show it. I've unknowingly worked around this issue for overlays in the past, I believe. I decided that I am not ever comfortable allowing jQuery to execute functions, contributed by Prototype to an element, that have the same name as a jQuery event type. The best way to prevent this is in the jQuery/Prototype event bridge I wrote. If we are handling a jQuery triggered event, and it is not a "custom" event, I remove the matching Prototype-contributed function from the event target if one exists before delegating to the jQuery trigger function. After jQuery's trigger function has executed, I re-attach the function to the element. Again, the jquery-prototype-custom-event bridge repo in the Widen organization should fix this issue for me if you integrate it into your project, as well as provide you with a bridge between jQuery custom events and Prototype custom event in your project. For example, it will allow you to handle & trigger Tapestry client-side events using jQuery. -- View this message in context: http://tapestry.1045711.n5.nabble.com/t-zone-and-Bootstrap-s-collapse-menu-tp5720122p5720128.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
