Wrong transition when using back/forward browser buttons #1867

Closed
IgitBuh opened this Issue Jun 21, 2011 · 6 comments

Projects

None yet

8 participants

@IgitBuh
IgitBuh commented Jun 21, 2011

The transition effect is not performed correctly when using back/forward browser buttons.

How to reproduce (tested with iOS 4.3.2 and Android 2.2):

  1. Create 3 pages (A, B, C)
  2. On page A create a button-link to B with transition "flip"
  3. On page B create a button-link to C with transition "slide"
  4. Load page A in browser
  5. Click the button. You'll be navigated to page B with the a flip-effect
  6. On page B click the button. You'll be navigated to page C with a slide-effect
  7. Click browser back button, you'll be navigated to page B with a reverse-slide-effect,
  8. Now click the browser forward button and you'll be navigated from page B to page C with the flip-effect - which is incorrect!

It seems the page history remembers only the transition effect that was used to get to it, but not the transition effect that was used to get from it.

@scottjehl
Contributor

Sounds like we need a condition that says, "when we think it's a "back button" click, use the transition from the current page, rather than the page we're going to...

@scottjehl scottjehl was assigned Jul 7, 2011
@toddparker
Contributor

Is this still an issue with 1.0.1?
Also please test on master (1.1-pre): www.jquerymobile.com/test

@agcolom
Member
agcolom commented Mar 17, 2012

@toddparker @scottjehl here's a jsfiddle to illustrate:
http://jsfiddle.net/agcolom/qeqB2/16/show/

It is still present in latest

@toddparker
Contributor

Thanks for the jsfiddle @agcolom - we'll give this a look.

@adriancd

Here is another example of the same issue http://jsfiddle.net/645Xm/

If you use the buttons in the window then the animations go in the correct directions but if you use the browser back button with the right click menu on the second page then the following animation back to the first page is in the wrong direction.

@johnbender johnbender was assigned Sep 24, 2012
@gabrielschulhof
Contributor

The setup as described by the OP: http://jsbin.com/IFolanOW/493/
It still works that way.

@gabrielschulhof gabrielschulhof added a commit that referenced this issue Jun 9, 2014
@gabrielschulhof gabrielschulhof Navigation: When going forward, grab transition from current entry
Our history entries contain exactly one transition: The one used to arrive at
the entry. In addition, the index of the current entry and that of the previous
entry is updated before the value for the transition is computed. So, it makes
sense, when going backwards, to read the transition value from the previous
entry, because that value stores the transition that was used to get there from
where history is currently at.

However, when going forward, it makes no sense to read the transition value
from the previous entry, because that one stores the transition that was used
to reach it, not the transition that must be used to reach the next entry.

Fixes gh-1867
0ef499e
@gabrielschulhof gabrielschulhof added this to the 1.4.4 milestone Jun 9, 2014
@gabrielschulhof gabrielschulhof self-assigned this Jun 9, 2014
@jaspermdegroot jaspermdegroot modified the milestone: 1.4.4 Jun 11, 2014
@gabrielschulhof gabrielschulhof added a commit that closed this issue Jul 24, 2014
@gabrielschulhof gabrielschulhof Navigation: When going forward, grab transition from current entry
Our history entries contain exactly one transition: The one used to arrive at
the entry. In addition, the index of the current entry and that of the previous
entry is updated before the value for the transition is computed. So, it makes
sense, when going backwards, to read the transition value from the previous
entry, because that value stores the transition that was used to get there from
where history is currently at.

However, when going forward, it makes no sense to read the transition value
from the previous entry, because that one stores the transition that was used
to reach it, not the transition that must be used to reach the next entry.

Closes gh-7485
Fixes gh-1867
Fixes gh-4951
0c14e2d
@gabrielschulhof gabrielschulhof added a commit that referenced this issue Jul 24, 2014
@gabrielschulhof gabrielschulhof Navigation: When going forward, grab transition from current entry
Our history entries contain exactly one transition: The one used to arrive at
the entry. In addition, the index of the current entry and that of the previous
entry is updated before the value for the transition is computed. So, it makes
sense, when going backwards, to read the transition value from the previous
entry, because that value stores the transition that was used to get there from
where history is currently at.

However, when going forward, it makes no sense to read the transition value
from the previous entry, because that one stores the transition that was used
to reach it, not the transition that must be used to reach the next entry.

Closes gh-7485
Fixes gh-1867
Fixes gh-4951
8ea937f
@agcolom agcolom added a commit to agcolom/jquery-mobile that referenced this issue Nov 26, 2014
@gabrielschulhof @agcolom gabrielschulhof + agcolom Navigation: When going forward, grab transition from current entry
Our history entries contain exactly one transition: The one used to arrive at
the entry. In addition, the index of the current entry and that of the previous
entry is updated before the value for the transition is computed. So, it makes
sense, when going backwards, to read the transition value from the previous
entry, because that value stores the transition that was used to get there from
where history is currently at.

However, when going forward, it makes no sense to read the transition value
from the previous entry, because that one stores the transition that was used
to reach it, not the transition that must be used to reach the next entry.

Closes gh-7485
Fixes gh-1867
Fixes gh-4951
596ed33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment