Skip to content
This repository

Jumpy and blinky page transitions #455

Closed
woutervanwijk opened this Issue November 13, 2010 · 114 comments
woutervanwijk

As of A3, page transitions are still not smooth on many platforms so this issue is being used to track our progress on improving the situation. This is a multi-faceted issue because we need a smooth transition system that works across all our target platforms and maintains all the normal "web" behavior such as returning a user back to their original scroll position when re-visiting page.

This issue originally started out regarding the address bar on iOS and flashes on Android but has expanded to discuss our progress on the larger re-write that Jesse, Kin and Scott have been working on so I've added this intro and revised the title accordingly. All transition-related issues will be closed and push back into this issue so we can track them together. A solution to the symptoms seen will require a deep re-factor and re-approach so it makes sense to look at this issue holistically and any fix for one platform needs to be evaluated against it's impact on another.

In iOS, there is a noticeable blink of the un-rendered page (checkboards) while the page scrolls down to a previous anchor position, among other situations. On newer builds of Android, there is flash of the previous page when executing a transition.

Also, when using long pages Safari on an iPhone 3GS, the address bar jumps up and down after page transitions. Not always, but it sometimes does (especially when selecting the items at the bottom of the listview).

Safari probably figures that because of the hash-change, the address bar needs to be visible. It will hide it again. Because of that, the user experience is not great. In jQtouch, the hash doesn't change, and Safari doesn't show this behaviour.

Maybe it would be considered an Apple-bug, but for me it's quite an issue, and for others too:

http://forum.jquery.com/topic/iphone-safari-address-bar-jumps-down-after-page-transition

I really like jq mobile, so it would be great if it could be fixed in some way.

Fabrizio Giordano

might be considerd to implement the trick used in
http://www.20thingsilearned.com/js/twentythings.history.js

They used:
history.pushState
[ https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history ]

I do not know if webkit for iphone safari support that.

BTW at least is it possible to edit the hash tag from # to #! to be google search compliant?

Thanks
Fabrizio

Taylor luk

+1

This is very annoying

Georg Leciejewski

+1

really annoying

Greg Vincent

+1 Again. Ridiculously annoying when transitioning between pages.

Brady Archambo

+1 from me also

Brandon Aaskov

Not sure if this falls in line with this issue, or issue 568 (https://github.com/jquery/jquery-mobile/issues#issue/568), but from what I can tell, it's a matter of going from a page that isn't longer than the viewport's height to a page that is. In the first page, you'll see the address bar, and after changing the page, you'll see the page jump to hide the address bar.

To workaround this for now, you can dynamically set the min-height of .ui-page to whatever the device size is, but I'm still trying to find out how to determine what that device size is (I tested it just by hard-coding a value for the iPhone Simulator). Ideally (at least for my case), when the page is rendered, if the page is less than the device's height, this would happen automatically.

Scott/Todd, if the community agrees on this approach of setting the min-height to the height of the device (or the height of the viewport plus any status/nav bars), we can tackle that here at Brightcove.

Scott Jehl

Believe me, big +1 from the team on this one too :)

I did some testing and found it's not related to updating the hash, setting focus to the first focusable element, or calling silentScroll... so hopefully Brandon is on to something!

Brandon, can you send a pull request with that workaround? I'll be very happy to take a look!

Brandon Aaskov

Hi Scott,

Is there some way to get the device's height? I've looked around and haven't turned up anything yet.

Scott Jehl

hmm.. screen.availHeight ?

Brandon Aaskov

So, there seem to be two good ways to go about doing this.

If you're loading in jQuery Mobile stuff the way I am since I'm in dev (by pointing the js directory), then you can just call this at any point in your code:
$('.ui-page').css('minHeight', screen.availHeight);
Here I'm just applying a min-height to all of the .ui-page elements and setting it to the device's screen height.

However, the better way (I say better since it's documented already to work this way) is to modify the jQuery Mobile defaults, like so:
$(document).bind("mobileinit", function(){
$.extend($.mobile, {
metaViewportContent: "width=device-width, height=device-height, minimum-scale=1, maximum-scale=1"
});
});

Here I'm just adding the height value, which is not there by default.

This is working for me in keeping my page transitions from "jumping", but I'm curious to see if this works for others as well.

Since that has to happen after jQuery gets loaded, but before jQuery Mobile gets loaded, I had to change my setup a bit to get it to work. Based on that setup, users would be required to have jQuery separate from jQuery Mobile, which is not currently how the ant build process is setup, but perhaps that is the plan for the first release (similar to jQuery UI).

Alternatively, if we find that a lot of people are looking to use this option, maybe we can just make it one of the defaults? Time will tell, I suppose.

woutervanwijk

I tried the second option and it works well. Thanks! Are there any drwabacks in making it one of the defaults? If not, I suppose it should be a default, otherwise it would confuse new developers imho.

Scott Jehl

Nice work!
If this fixes the issue and doesn't interfere with taller pages ( as in, it acts as a min height), then let's roll it into the defaults.

Scott Jehl

We'll do some testing on all the devices here but my initial testing shows this fixes the address bar issue. Look for the commit soon! Thanks again.

patussay

The metaViewportContent solution is perfect but another problem arises when you decide to change the orientation of your device on the fly (at least for me), it doesn't dynamically change the size of the viewport, which apparently remains stuck on the old orientation value. You need to refresh the page to get the right view and so on.

Otherwise it's a big step forward since this visual problem does not seem so easy to resolve. By the way many thanks to the team for the great work they have already done.

tested with the latest rev.jqm + ipod 4g ios421

Scott Jehl

ahh rats!
Yeah, that's a pretty big problem actually. There are so many finicky issues with orientation change in iOS. I reported the issue to Apple where the layout zooms in on change when user-scaling is enabled, but so far they haven't released a fix for that one either.
We may need to look into setting a min-height on certain elements through CSS. Maybe the body element will work...?

patussay

CSS would be good but i think it's really a job for Mr javascript.

A quick 'console.log' test reveal that the event.orientation in jqm (circa line 389 w/o jq144) is never updated (iOS_421) and keeps the value "portrait" (if you start browsing in portrait) even if you flip your device to landscape.

On the other hand if you start browsing in landscape mode, the value is correct the 1st time but lost afterwards and cannot be recovered (until you reload your page), the fact is that the className is never correct unless you keep your device in one orientation from the start.

update: if you keep the original metaViewportContent from JQM (w/o "height=device-height" as mentionned above), the event.orientation is correct in mobile safari. Strange isn't it !

patussay

As a starting point, here is a solution for the address bar, it's not perfect and beware not to mix this solution with the jumping page issue that still must be adressed (and going to be a hard case).
Test it first without scrolling, it acts as the silentScroll should work, if you change orientation of your device everything is fine.

Of course, pages are intended to be scrolled and many unpleasant display issue appear if you act upon a link and you are somewhere in your page (perhaps some kind of default browser behaviour mixed with the lastScroll data sent to silentScroll() + loading of the page + ...? = it's a lot to take care in a short time). The problem also appears when the page is in cache but the effect is less visible.

But 'back to our sheeps'.

Here's what i did, i worked from the solution 1 of brandon (as it seems impossible to mix device-width and device-height with iOS, as said above, the orientation is not updated) :

if(event.orientation) {
* in line 390 of jqm (standalone version without jq.144)
    [change] 
        $html.removeClass( "portrait landscape" ).addClass( event.orientation );
    [for]
        $html.removeClass( "portrait landscape" ).addClass( event.orientation ).css({'min-height': screen.availHeight});

* i also added beneath it a setTimeout, sometime the address bar show up especially when you change your orientation
        setTimeout(function() { window.scrollTo(0, 1); }, 20);//could be connected with silentScroll ?
}//end event.orientation

* need to add few lines at the beginning of your css file, otherwise the page is truncated during animation
        html {
            position:relative;
        }

UPDATE

Forget about the above block of code as the css rule creates problem on Safari:desktop (doesn't like position:relative in this situation),
but for testing purpose, put this in your jqm.js file

if(event.orientation) {
    //use class for every browser
    $html.removeClass( "portrait landscape" ).addClass( event.orientation );

    //only mobile
    if($.support.touch) {
        $html.css({minHeight: screen.availHeight, position: 'relative'});
        setTimeout(function() { window.scrollTo(0, 1); }, 20);
    }
}

Tested only on iOS4.

Brandon Aaskov

In jquery.mobile.event.js in the special_event.orientation function elem.clientWidth and elem.clientHeight only report correctly the first time the screen renders. Once it rotates, they report the device's height and width.

Then, I tried taking out width=device-width, height=device-height from the metaViewportContent default (jquery.mobile.core.js) altogether and everything seems to be working wonderfully, including rotation. patussay, can you give that a shot and see if it works for you?

patussay

The bare minimum for iOS (and maybe other mob-systems) seems to be the following rule

metaViewportContent: "initial-scale=1, maximum-scale=1",

and it acts just like the default one in JQM

metaViewportContent: "width=device-width, minimum-scale=1, maximum-scale=1",

But what about the url bar ? my attempt was to hide it from the view and the following metaviewport rule fails to do so, (I must admit that it's a pity that your 2nd solution fails because of the orientation, it would have been perfect and would have spared a lot of time and energy for such a thing that's normally done with a setTimeout).

This does not work because the address bar is always visible, or did i miss something with your explanation ?

mesca

To get the real visible height/weight, I use something like:

window.onorientationchange = function() {
    h = window.innerHeight ? window.innerHeight : $(window).height();
    w = window.innerWidth ? window.innerWidth : $(window).width();
    // Call your resize function
    // update_orientation();
}
$(window).trigger('onorientationchange');

It will report the correct width and height for the visible part of the viewport. Works well in any orientation and also in full screen mode. Then, in update_orientation(), you can detect the height of the page and adjust it if less than the reported height.

urlsangel

This is a big issue for the team here too.

Will there be a fix for this in the next release? If not, any idea when this will be looked at?

Taylor luk

Same here, Any update on this issue?

It will have huge impact on user experience

Fabrizio Giordano

do you think we can get some clues or inspirations from the way this webapp is managing the URL. They change the hash without triggering the navbar appear.

http://m.untappd.com

[ i'm not affiliated or related to untappd ]

avibha

+1

Jesse Streb

I just took a look at http://m.untapped.com and for me the address bar always appears when the hash changes. Are you seeing something different? For example if I am on the pub tab, scroll down the page and then click on one of the pubs the page jumps back and shows the address bar. Is this different behavior then what you are seeing?

Scott Jehl

So Todd and I were just chatting about this and here's what we're thinking:

The address bar showing and hiding doesn't often cause much of a problem in regards to transition smoothness. For example, if you go to the homepage of jQuery Mobile docs, and click the first link, the transition is quite good on iOS. Yeah, the address bar shows, but it's smooth overall and the transition works as you'd expect.

The real problem occurs when you scroll down the page and then click a link. Ideally, the transition would occur from the existing scrollTop to the correct scrollTop of the page you're transitioning to (which is saved in data when a page has already been visited). Unfortunately, this is the part that doesn't work quite right, but I think it's the fault of our own sequence of events (and not a browser issue).

Maybe we should first direct our efforts there, since it's clearly a problem that we can solve. You can test this in Chrome as well; just scroll far down a page and click any link. The transition will blink rather than working properly.

Jesse Streb

Yes, I think there are a handful of issues here.

  1. if a page's height does not take up more then a 100% of the window then after the transition the page shifts down because the silent scroll will not hide the address bar on the shorter page. ( I just pushed a pull request to address this. )

  2. If a user scrolls down the page, clicks on a link to navigate to a new page, then the transition does not look right. This seems to be a new issue, specific to HEAD. The alpha 2 branch seems to do this correctly.

  3. As Scott and Todd mentioned returning to page that you had previously scrolled down on jumps to the bottom of the page after the transition. Ideally there would be no jump but rather you would just slide over to the previous scrollTop.

  4. You will always see the address bar appear because an a href was clicked. As Scott and Todd mentioned this seems like the right thing.

Anyway, I will start looking into the suggestion that Todd and Scott have made about transitioning to the existing scrollTop.

Scott Jehl

Awesome - sounds like we're on track now. Thanks Jesse

Jesse Streb

Hi all,

I pushed up a fix to make the pages not jump around during the transitions. We looked into scrolling from where we were in the page to the new page, but there are too many performance problems for this to work well. What we see now is similar to alpha2 where we scroll up to the top of the page and then scroll over.

New to this update is that the page does not go down and then back up during the transitions, which is what the original bug was. If the user hits back we will take them back to the page and then scroll them to where they were in the page. (known issues is that on iOS the scroll down to where they previously were can result in seeing some flicker.)

Please let us know if this improves the jumpiness of the transitions.

  • Jesse
Todd Parker

Jesse's fixes make this look much better. I'm keeping this issue as high because he's working on even more refinements but it's no longer a blocker.

Scott Jehl

Nice work, Jesse.
One thing I noticed, and I'm not sure if it's related: in Safari (desktop), the scroll height is much taller than the page itself. Maybe it's related to the 120% height thing? Doesn't seem to show up on iOS.

Todd Parker

After doing more testing, the page blink that happens is still pretty bad so we need to keep working on this before it's not a blocker.

Nicholas Clark

Here is my suggestion for improving sliding transitions. I think this is relevant to issue 3 that Jesse mentioned on Jan 25th.
http://forum.jquery.com/topic/improving-page-transitions

The basic idea is to put a blank page in-between the transition from page A to page B. If you perform the scroll on the blank page, the user will never see the content jump around and the transition should look pretty smooth.

BMCouto

I would really need to see this solved in order to use it in my upcoming projects.

Todd Parker

Transitions cause a blink of the previous page on newer builds of Android. We have been known this was an issue since A3 but I want to link up this newer issue #1124 that provides more detail on the Android situation. I will be closing 1124 so we can just track all transition work under this issue.
#1124

Thread on the forum is also has useful ideas and commentary:
http://forum.jquery.com/topic/page-transitions-are-still-blinky-on-android-2-2-2-3-jqmobile-a3#14737000002041003

Taylor luk

The page transition still "blinks" badly on jquery mobile A4 release on Android 2.2

Todd Parker

We were working on trying to land some transition fixes for A4 but we just didn't get there in time so they are actually the same as A3. This is a going to be a big focus for us in the next few weeks so beta should be a lot smoother.

cmsfruit

I too, am experiencing this issue with JQM a4 and iOS

Brian Antonelli

I'm seeing this on JQM a4/iOS when navigating to a static page. This only happens on a single page and only the first time its rendered. Going back to it (data gets updated via DOM) never shows the flash again. I'm running this inside of a uiwebview so I know its not an issue with the safari toolbar.

badtoto

+1 hope it will be fixed in beta :)

Josh Rose

seeing this as well on a4.1 + droid x

abdlquadri

Hi all, Good work here. I hope this sorted out soon. Keep up.

Kin Blas
jblas commented April 27, 2011
ha17
ha17 commented June 01, 2011

@brandonaaskov's fix worked for me when it was flickering in iOS 4.3 on the iPad:

$(document).bind("mobileinit", function(){
$.extend($.mobile, {
metaViewportContent: "width=device-width, height=device-height, minimum-scale=1, maximum-scale=1"
});
});

Still flickers on a flip but not on a normal slide, etc. I'm using A4.1

Tobias Bosch tbosch referenced this issue from a commit June 04, 2011
Commit has since been removed from the repository and is no longer available.
Tobias Bosch
tbosch commented June 04, 2011

Hello, just created a solution for android (see the above pull request).

For this I did the following:
1.) add a -webkit-transform:translate3d(0,0,0); to the body of the page. This fixes the white flickers at the start/end of the animations.

2.) reimplemented the animations using css3 transitions instead of css3 animations. This fixes the problem that the old page shows up for a moment at the end of page transitions.

I also implemented a test for android browsers, so on iOS or other devices nothing changes.

What do you thing about this?
Tobias Bosch

Tobias Bosch tbosch referenced this issue from a commit in tbosch/jquery-mobile June 04, 2011
bugfix for issue #1673, using helper function from previous bugfix fo…
…r issue #455
08e71fb
Tobias Bosch tbosch referenced this issue from a commit in tbosch/jquery-mobile June 07, 2011
fix for issue #455, still allow native select menus a1848f5
sherkal

Cant believe this isnt fixed in the lastest build yet..

Todd Parker

@sherkal - It's a pretty complex problem to solve and we needed to do a lot of re-org and re-factoring to the page scripts first before we could try to finesse the transition smoothness. Once we get beta 1 out, this is one of the big ticket items for beta 2.

Scott Jehl

We've spent the last few days on transitions and just landed the best we've got in master. The address bar rarely shows up (in iOS at least), and blinks are mostly gone. Please test and let us know if you see any issues! Thanks

Scott Jehl scottjehl closed this June 17, 2011
Taylor luk

Awesome, you are the man.. Where are you located I want to buy you a beer :)

woutervanwijk

Sounds good. I will try it, thanks!

Tobias Bosch tbosch referenced this issue from a commit in tbosch/jquery-mobile June 22, 2011
Revert "bugfix for issue #1673, using helper function from previous b…
…ugfix for issue #455"

This reverts commit 08e71fb.
2f99eac
Tobias Bosch tbosch referenced this issue from a commit in tbosch/jquery-mobile June 04, 2011
bugfix for issue #1673, using helper function from previous bugfix fo…
…r issue #455
5fdf6be
Tobias Bosch tbosch referenced this issue from a commit in tbosch/jquery-mobile June 07, 2011
fix for issue #455, still allow native select menus 3c96861
Tobias Bosch tbosch referenced this issue from a commit in tbosch/jquery-mobile June 22, 2011
Revert "bugfix for issue #1673, using helper function from previous b…
…ugfix for issue #455"

This reverts commit 08e71fb.
5244829
Tobias Bosch
tbosch commented June 23, 2011

Hi scottjehl,
sorry, but the page transitions are still not working on android in 1.0b1.
However, the pull request 1785 I added does work well (your closed it already). Please have a closer look at it and try it.

Tobias

miscs
miscs commented June 27, 2011

please reopen this issue - i tested 1.0b1 with several android devices and it flickers nearly all the time. to make it worse if you slide from A->B->C and then back it flickers AND you sometimes see the "wrong" site for a second...

Todd Parker toddparker reopened this June 27, 2011
Charlie Croom

+1 @miscs confirmed on my device, 1b1 and nightlies as well

Charlie Croom

Also, for the time being, I found adding this code from another thread:
.ui-page {
-webkit-backface-visibility: hidden;
}

To my custom CSS to solve the problem a tad. It does, however, make the transitions feel slightly more sluggish. It also does a small choppy adjustment at the end of the transition. I'm using slide transitions, didn't test for possible negative effects on others, but this is a quick hackfix for those trying to resolve flickering and white flashes on transitions like I was.

Todd Parker

This property can really increase memory and CPU use so that's probably why they feel sluggish now. You may also see crashes.

Charlie Croom
Benjamin Charity

Big 1+

I know it's a tough issue, any idea on timing for the next release?

markusweb

the problem is still here. iphone 3gs, but not in ipad, ok here the address bar is always on and not beeing hidden.
so may problem is: the first click on any page will cause to have the addressbar displayed for a very short time. then the transition is performed. when i now go back to my index.html and click any other link the page is loaded, the address bar keeps hidden and everything is ok.
as a web app this is only a small bug, maybe you could ignore it. BUT i am using the same html-files to build an app with phonegap. here the problem is, that the first click will result in a blank page. even the loading message is hidden, only the animated loading icon is visiable. after i go back and click on any other link everything works like expected.
so i think this is connected to this bug here.

so as the address bar is displayed on ipad it would explain, why i only have this problem on iphone.

see http://forum.jquery.com/topic/first-page-transistion-in-phonegap-blank-screen-before-transition

EDIT:

i have added

.ui-page {
-webkit-backface-visibility: hidden;
}

to my page, now it (seems to) works.

ricwantsutudone

I'm seeing these problems too on Android 2.2.1. Pages flicker during transitions and sometimes flicker and then remain on the same page. I am trying to use with Phone Gap as well if that helps.

Ghislain Seguin
Collaborator

Check out the transitions branch and see if it makes things better. Please let us know if you still see the issue.

mmtg
mmtg commented July 21, 2011

@gseguin I just tried the transitions branch and I am still seeing the same blinking issue on transitions. #iOS4

mmtg
mmtg commented July 21, 2011

Confirming that this css fix works for me:

.ui-page {
-webkit-backface-visibility: hidden;
}

ricwantsutudone

I tried the new fork. I still get a page flicker. The page appears to load then right when it completes, I get a flash back, then the page finally loads completely. Android platform.

Faolan C-P fcheslack referenced this issue from a commit in fcheslack/jquery-mobile January 26, 2011
[#455] For the transitions we now have overflow: hidden in order to l…
…imit the flickering. We always scroll to the top before we start our transitions in order to make it scroll. The CSS changed to have overflow: hidden during transitions and have a height that is larger enough to keep the address bar hidden.
378fb51
John1John1John

Using the latest JQM as of July 29, 2011 on an Android/HTC Evo.

I have been pulling my hair out over the "blinking" where you are on page 1, click for page 2 and after page 2 has displayed it flashes back to page 1 before settling down on page 2. Then I found this thread and at least I know it is being addressed.

As a quick/temp fix I turned transitions off. Now I have a new issue where a single tap on a page 1 link will cause it to briefly display page 2 before it blows past it to page 3! So I never need to tap a link on page 2...it goes straight there! Same thing happens on the way back. A tap on the back button on page 3 will result in page 2 being briefly displayed and then it jumps back to page 1 without a tap.

Is this issue related to the transition/blinking problem? Or should I pursue this in another thread, document my case, etc.?

pythonflying

Droid X with 2.3. I have the same issue as John1 above, regarding clicking on a link , it briefly displays the page and then it jumps to another page (from the link embedded in the div) automagically. Appears random when surfing around the site pages. It dowsn't do this in Chrome or Safari or Keynote MITE emulator, only on the actual Droid X 2.3 phone.

Mark Kamoski

+1.
FWIW, I have the same issue on...
Optimus V
Android 2.2
JQM 1.0b1
...and I have tried all of these but none of them fix the issue...

.ui-page {
-webkit-backface-visibility: hidden;
}

<script type="text/javascript" charset="utf-8">
  $(document).ready(function() {
    // disable all ajax nav
    $.mobile.ajaxLinksEnabled = false;
    });
</script>



<script type="text/javascript" charset="utf-8">
  // turn off all page transitions
  $(document).bind("mobileinit", function(){
    $.mobile.defaultTransition = 'none';
    });
  </script>

....so is there ANY solution to this at all?

Please help.

  • Mark Kamoski
Scott Jehl

John1John1John: the issue you mentioned should be fixed in latest - are you using beta1? If so, try latest.

Mark, the option to disable ajax is ajaxEnabled, not ajaxLinksEnabled. Let me know if that helps. http://jquerymobile.com/test/docs/api/globalconfig.html

John1John1John

scottjehl: I'm using 1.0b1 and seeing both the "blink" issue and the one I described above where a single tap/click takes you to the next page as well as the one past it. I'll see if I can grab a few minutes and put together a simple demo/vid to document.

Ghislain Seguin
Collaborator

@John1John1John: Can you test against the transitions branch?

John1John1John

unless there is an already-built version of it somewhere that I can link to, building it from the transitions branch is probably above my pay grade!

John1John1John

I assume I am using the very latest beta as I'm using your hosted version from here,

http://code.jquery.com/mobile/1.0b1/jquery.mobile-1.0b1.min.css
http://code.jquery.com/jquery-1.6.1.min.js
http://code.jquery.com/mobile/1.0b1/jquery.mobile-1.0b1.min.js

The two issues I am referencing are,

1) page changes are accompanied by a brief blink or flash of the previous page after you have already completely transitioned to the new page. I assume this is the issue described here as Issue #455.

2) sometimes a single tap/click on a link will cause a jump not only to the requested page but to another one without a second tap/click.

I am seeing both issues in my app but I have noticed that number two is much more frequent when I have data-transition="none" while number one is always there when I have data-transition="slide". To be clear however, both problems seem to be intermittent; they do not always happen on every click but they do seem to happen 50% of the time.

Here is a link to a short video I just made showing these problems,

http://www.winpath.com/JQM/JQM-Test-08-03-11/

During the first 20 seconds you can see problem number one quite clearly; this code has [data-transition="slide"]. At around 22 seconds, 33 seconds, 46 seconds and 52 seconds you can see problem number two; this code has [data-transition="none"].

Thanks for your help on this...If there is something I'm doing wrong I'd love to know!! :)

John1John1John

thanks to gseguin for providing me with links to a latest build.

I tested against that build and, with transitions set to "none" I saw no issues with blinking or with more than one page loading from a single tap/click. It did feel a tad sluggish in its responsiveness to a tap/click but based on the overall responsiveness of phones I'd say it is acceptable.

when I set my transitions back to "slide" the problems came back but not quite as severely as before. Now it seems that a tap/click on a link results in a pretty smooth transition BUT when I then click the Back button (in the header...not the hardware back button), it almost always does some jerky/blinky stuff. this would be unusable and I'd give up the nice transitions to correct this behavior.

I'm really hoping the released version can improve on all of this. I know the contributors are working hard on it and it is greatly appreciated!

pythonflying

The video from John1 is exactly what mine does. It's as if a link tag in the div is randomly being fired off no matter what position it is located in the subsequent div.

Mark Kamoski

All -
FWIW, the video from John1John1John shows exactly what my app does too.
To workaround it (for now) have set all buttons to use data-transition="none" and the problem goes away, but unfortunately, so too (what would be) nice looking page transitions also go away.
Please help jQuery Mobile team.
I really love jQuery Mobile, even still, and I have published my app with it rather than with App Inventor.
I really wish I could keep using jQuery Moblie and I might, despite this problem-- but it would be SO nice to have it fixed.
I am not sure if Sencha Touch is worth the learning curve given that a regular Android app built with Java and the XML code-infront template model would probably be similar startup cost concerning learning curve.
Thank you.

  • Mark Kamoski Hmmm.
Scott Jehl

Thanks. Just to be clear, we've probably invested more time in this issue than maybe any other - we're definitely focusing on it. :)

Transitions will be a major focus for b3, as we're looking to move over to css transitions instead of keyframes, and with that comes potentially better transitions in Android.

Thanks!

John1John1John

thanks for your hard work scottjehl!

just to clarify, are these two issues (blinky and auto-click-through) both related to transitions? and are you able to duplicate them both?

John1John1John

just to clarify, are these two issues (blinky and auto-click-through) both related to transitions? and are you able to duplicate them both?

Kin Blas

@John1John1John1

There was a bug in beta1 where we were firing off our ajax/page-transitioning on vclick, but due to quirky event implementation differences between the platforms it was hard for us to catch the synthesized clicks that follow. This is the cause of the 2nd ghost click you were seeing.

For beta2 we went back to our old strategy of updating visually on vclick and doing the ajax/page-transitions on the click event which is really the only way to work somewhat reliably on all the platforms and avoid the quirks/bugs.

pythonflying

That's cool, does that mean a fix is forthcoming? These 2 issues are all I see on my Droid, JQuery Mobile works flawless in every other aspect, for me, anywho.

Kin Blas

@pythonflying

The click fix is already in beta2 which is available. We have fixes for the transitions in the "transitions" branch. I'm not sure how in sync that particular branch is, but we've been playing with switching to CSS3 transitions which shows some promise on more Android devices ... note I said most ... some Android devices like the Motorola Xoom still display flashing with even the most basic of test cases (no jquery-mobile involved).

I'm hoping to land the transitions branch on the HEAD sometime within the next few days once the guys on the team have had a chance to bang on it with the devices they have. If you'd like to try it out, feel free to pull the branch and give it a whirl.

scottoliver

I'm not sure if the transitions or just changing pages is the culprit here, but I find when I click on an item in a listview, the page with the listview jumps to the top before the transition animation (verified on iPhone 4 with iOS 4.3, Chrome 13 and Firefox 5). When pressing the back button generated by jQuery Mobile, the listview page starts at the top, then jumps down to the item that was clicked when using the href property of a anchor tag. If $.mobile.changePage() is used, the listview jumps to the top on the first click, but does not return to the item clicked when back is pressed.

Like I said, I'm not sure if the culprit is the transitions or the actual act of changing pages, but this seemed like a good place to report it.

Update: after turning transitions off, it solved the problem above most of the time. On the iPhone 4 it can sometimes briefly be seen at the top of the listview page after pressing the webapp's back button. Overall, however, the app has a better experience when the transitions are turned off.

Paulo Almeida

Hi pythonflying I've downloaded the transition brach but it still blinks when I go to a internal link in Android, for what version do you guys expect to have it fix.
Great Jobs by the way.

pythonflying

I turned off transitions but the "click through" to a subsequent page issue persists (Droid X, 2.3). I don't see any jumpy or blinky issues with transitions turned off. If I had to pick one, I would say the clckthrough bug is far worse than blinking transitions! I would like to add, that in John1John1Johns video above from 8/2, watch when he clicks "Upcoming Events", the 5th time, the "Outdoor Drawing" button resides in the exact same position and gets fired, it's as if these buttons are layered on top of each other and the click is bleeding through. It does this more than 50% of the time on my phone.

Paulo Almeida

I have downloaded the transition branch and turn off the transtion effect and I do not see any click through problem but I only have one html file and I'm using internal links to move from section to section

pythonflying

Paulo, I only have 1 html file and internal links also. Are you running android gingerbread 2.3?

Paulo Almeida

I'm running a LG optimusX2 with 2.3.4 OS

rmahnovetsky

HUGE +1 for me. Im using motorola Xoom

This only occurs when I use hardware acceleration mode. Otherwise it is fine. But without hardware acceleration scrolling is too slow.

rmahnovetsky

No more flashing for me, except for the footer nav bar which still flashes but I guess that it another issue. In my case the problem was overflow. I had li elements and text areas that grew beyond 100% width of the screen and this cased the flashing or maybe redrawing. It also made the app run really slow.

The other issue I had was the async calls to the web db. This also cased flashing because the screen would render then some small time after the data will return and I add the data to the screen casing a little flash. To fix this I created a transition handler to render once the async call came back.

Mathieu Godart

It seems like I have the same issue. To simplify the explanation, I have done a simple test case: https://gist.github.com/1165071

The test case links 0 and 2 are working fine (transition with no blink), but the test case link 1 blinks. The difference between 1 and 2 is that the page change is done by the HREF for test case 1 and programmatically in test case 2. Do you think this could be a lead? Or have I overlooked something?

Kin Blas

@MrDart

What device/platform are you running your test on? I see no differences on some of the Android devices I'm testing on.

@rmahnovetsky

How are you turning off Hardware acceleration? I thought config switches were for apps you packaged yourself, or are you using Phone Gap? The browser on the Xoom is already hardware accelerated, but I wasn't aware of any switches that allow you to turn it off for the built-in browser.

  • Kin
rmahnovetsky
Mathieu Godart

@jblas

I'm testing this code with Safari Version 5.1 (7534.48.3) on Mac OS X. But it seems to work fine on the iPhone.

netline

Hi,

I have a problem of "blinking" transition, but for me it's link to the iPad keyboard.

My forum post : http://forum.jquery.com/topic/transition-goes-wrong-when-ipad-keyboard-shows-up
Someone with quite the same issue here in bug tracker : #1983
A video a the problem : http://www.youtube.com/watch?v=iT8-YPETkAk
And a page to test on iPad : http://demo.netline.lu/jqueryMobile/

I don't know if it's the same "blinking" as here, but it's very annoying...

Kin Blas

@netline

I opened a separate bug regarding your problem:

#2343

  • Kin
kenjiru

This is very annoying on Android.

Android 2.2 on Samsung Galaxy S.

Todd Parker

Hi all - At this stage, we've really tried pretty much every technique or approach that might improve the smoothness of transitions and reduce blinkiness and it's a fine balancing act between compatibility and accessibility. The gist is this: because all the pages actually share the same viewport, we need to scroll the document to jump up to the top of the page before a transition (or restore a scroll position) so the only way to make transitions smoother is to have the page your on and the one you're transitioning to be in their own containers with overflow. Now that iOS5 supports this, we are going to encourage browsers makers to follow suit and we've proactively added features to leverage iOS for way better transitions and true fixed toolbars.

We were also hoping that migrating from keyframe-based page animations to CSS transitions would improve animations, especially in Android but we were disappointed to see that some devices were a bit better, others a bit worse but most were a wash. We've decided to hol doff on rolling this out because FF and Opera's mobile support for transitons isn't quite ready.

We know that Android's transitions aren't great and that Honeycomb is especially blinky but we just can't find a solution for this right now because Android is frankly pretty darn bad with hardware acceleration and buffering. In any case, we will continue to work on this and hope that native support for scrolling will have quick uptake because that is going to be the true way forward is we want to support cross-browser.

This is still incredibly important for the project so this will be a priority even after 1.0 goes out. There's lot of smart people here, so please do weigh in with ideas!

Mai van Quang

This is very annoying

Todd Parker

@quangmv - I agree :)

Like I said above, we're exhausted every option to smooth this out so we're actively lobbying browser makers to improve their support and performance for native overflow: CSS support. iOS5 already has this and I know RIM and others are making strides here too. We already have a great system in place for making transitions and fixed toolbars pretty much perfect as platforms support this -- just turn on the touchOverflowEnabled feature and test the pages on iOS5 and you'll see where we're heading and how much better this is.

http://jquerymobile.com/demos/1.0rc1/docs/api/globalconfig.html

Jake Olefsky

As an interim concession, would it make sense to temporarily turn off the visibility of the page that is about to flicker/jump? I think that it would be preferable for the page transition to have a flash of white instead of having the scroll position visibly jump around.

Todd Parker

Whenever there was a flash of white, it was very distracting and this could last for almost a second so it might freak people out that it blanks out. We add classes when transitioning if you want to make this customization on your end to test.

Timmy Willison timmywil referenced this issue from a commit January 26, 2011
[#455] For the transitions we now have overflow: hidden in order to l…
…imit the flickering. We always scroll to the top before we start our transitions in order to make it scroll. The CSS changed to have overflow: hidden during transitions and have a height that is larger enough to keep the address bar hidden.
a0504fe
Karol Fabjańczuk

Ok, what abut this idea - transitions are jumpy because next page have to be scrolled to top. What about we do like this:
#1. Instead of loading page BEFORE we change the page with nice transition, without the jump to the page only showing "loading...". So we change the page before it is loaded. We just have one small page which is always scrolled to top
#2 After the page loads we change "loading..." with page content with page content or information that we couldn't load page + BACK button.

I'm thinking in a good way or is it rubbish idea?

pythonflying

Hi, I just tested with 1.0rc2 for Droid X / Gingerbread and am very happy that the links jumping to secondary/different pages (original jumpy issue) are forever gone. Thanks!! I haven't tested with animations turned on yet (blinky), but i guess that is still an issue(?). The former was much more important to me. Kudos to whoever fixed that bug!

Karol Fabjańczuk

@pythonflying: Checked with iPad - still the same jump to top before ajax page.

Todd Parker
Karol Fabjańczuk

@toddparker - the viewport scrolling (to top) is done always, even when transitions are off.

This jump before transitions is the only thing that keeps me from using jQuery Mobile as it's the easiest and most compatible mobile framework out there. I think that I'm not the only person who would sacrifice compability to fix that.

Maybe you can give me some hint how to turn it off so I can experiment with some solutions? I commented out almost all code which I thought was responsible for this jump but it still occurs - is there some tricky way how the jump/scrol top is done?

Regards.

Todd Parker

@blknight - can you create a new issue for this? If transitions are off, I think we shouldn't scroll to top. If you ca provide a test page, that would be helpful

Todd Parker

Sorry, I was thinking that you were saying that the scroll happened with Ajax off, but this is still Ajax-based nav with multiple pages in the DOM but no transitions. In that scenario, we still need to scroll to the top otherwise, if you were scrolled halfway down the page and clicked a link, the next page would have a ton of whitespace above it. You can turn off Ajax nav if you don't want transitions -- the whole point of the Ajax nav system is primarily to have both pages in the DOM so as can animate between them.

Karol Fabjańczuk

@toddparker - yes, you are right about Ajax scroll to top - that's what I meant.

The problem is that I want both Ajax request + animations without scroll to top. I can see from comments that it's hard to achieve so I would chill out. I still think that this can be achieved if we first switch the page to our "loading page" (maybe with no content so we can scroll to top without visible jump) and then show loaded content.

Unfortunately I can't find way to remove scroll to top behaviour so I can't check above scenario myself. As I said I will chill out, thanks anyway. Regards.

Kin Blas

@blnight

Your not the first to ask for this option, and perhaps we should consider a way to turn it off via a config option. The problem that @toddparker was referring to above was that without doing the "scroll to the top", transitions to new pages will result in a change in the document height ... the problem is different browsers do different things when this happens. Some stay at the current scroll offset even when the document height is less than that offset, resulting in what looks like a blank page, while others will adjust accordingly showing you the bottom of the new page content. Aside from this problem, it just looks wierd to see a transition that doesn't involve the top of a document.

Believe me when I say we have tried several times to figure out how to make this smoother, for example offsetting the rendering of the new page by the current scroll position during the transition, etc ... but we always get bitten by blinky/flashing rendering when we fix the scroll position for the new page because the browser thinks it hasn't rendered that part of the document.

I just wanted to give you a feeling of the types of issues you may come up against if we give an option to turn this behavior off.

Karol Fabjańczuk

@jblas - thank you for the response. I don't want to take your time so I will just say that I'm really impressed by your work. Thanks and take care.

Todd Parker

Be very careful if you add -webkit-backface-visibility: hidden; to your styles. We've seen this cause all sorts of odd behavior in Android with form inputs.

Guy

Don't know if this will help iron this out, but I noticed that when my <body> element contained a direction:rtl the reverse slide transition flickered badly.
Setting the direction on the page element (.ui-page) seemed to fix this.

Todd Parker

We have a new centralized ticket #3217 for the page transition re-factor we're doing for 1.1 here so I'm closing these older issues to keep things focused:
#3217

Todd Parker toddparker closed this December 04, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.