Ryan,

I'm curious to get your thoughts on this ticket.

When an app uses transitions, it will queue up calls to `showView()` if the app is currently transitioning between Views. The reason I added this queueing is to get around issues with applying multiple transitions to a single Node at the same time, and Y.Transition not calling my callback function when they complete.

Currently, the app will run through all of its queued up transitions, so rapid hits of the back/forward button will cause the calls to `showView()` to get queued up and then app will cycle through them all. I agree with Steven that this is not desirable, but the reason I chose the FIFO queue approach here is to maintain the contract of the `showView(newView, viewConfig, callback)` method, which will always call the `callback` function and pass it the new active view. See: http://stage.yuilibrary.com/yui/docs/api/classes/App.Base.html#method_showView

For 3.5.0 GA, I could adjust the contract with showView's callback that would state that the callback would only be called if the view was "attached" to the app (i.e. rendered to its DOM). This would allow for my to use a LIFO queueing approach, and during the dequeueing phase I could pop off the last item from the queue and reset the queue back to a new array. I could then transition from the last-attached view to the new view and skip any intermediate transitions which were queued up from rapid calls to showView.

For 3.6.0 I want to explore whether this transition limitation of not being called back when a transition completes if multiple transitions are applied to a single Node is a browser limitation or simply a Y.Transition one; my gut tells me it's the latter.

I feel like switching to a LIFO queue that dumps any previously-queued items could result in unexpected behavior. I would expect the queued callbacks to run, and I can easily imagine an implementor depending on them to run for state-related reasons, then being surprised if they don't.

I think skipping transitions for all but the last queued view would be fine (no need to make the user wait through all those transitions), but I think the showView callbacks for the intermediate views should still be executed in order. But I've never worked with Y.Transition, so I'm not sure what limitations it imposes here.

Closing out bugs checked in to 3.5.0.