Jumpy and blinky page transitions

[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.

[fabriziogiordano]

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

[speedmax]

+1

This is very annoying

[schorsch]

+1

really annoying

[Vincentgr]

+1 Again. Ridiculously annoying when transitioning between pages.

[bradya]

+1 from me also

[brandonaaskov]

+1

[brandonaaskov]

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.

[scottjehl]

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!

[brandonaaskov]

Hi Scott,

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

[scottjehl]

hmm.. screen.availHeight ?

[brandonaaskov]

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.

[scottjehl]

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.

[scottjehl]

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