If you load a longer page, scroll down, then click a link the next page that transitions in appears at the scroll position of the previous page instead of at the top. If you then go to a very long page, then hit Back, you can be scrolled way further down than the height of previous page so it looks blank. This sort of kills mini support so it's worth trying to fix for A4.
To see this, go here:
Steps to reproduce the issue:
Pages & Dialogs > Anatomy of a page > scroll to the bottom > Hit Back = blank page
I've run into this problem too, here is an example of how I came across the issue:
I think I've found a work-around (in my case) which includes just adding the data-position="fixed" to my bottom toolbar.
I also ran into this issue... try going to http://jquerymobile.com/test/#/test/docs/lists/docs-lists.html , scroll down, open e.g. "List with count bubbles" and then go back...
Adding some notes here, also to get notifications of comments here.
More notes to self Customising content for Mini http://dev.opera.com/articles/view/opera-mini-web-content-authoring-guidelines/#customising-content
THEREFORE, reality check this idea: test for Opera Mini and, if so, bypass transitions and cut straight to the chase. Seem reasonable? If this hunch os correct, we may need to go into bare-bones commando mode for Opera Mini.
This surfaces a profound functional requirement for navigation.js; We need agility to arbitrarily skip some steps, and bare-bones some others.
At the moment this evokes the Gamma and Helm Builder design pattern. TL;DR: a director with smarts to know what builder, or what aspects of a process, to invoke.
You know we could do all the smart things and still get scuppered by long lists. Seeing as Opera Mini renders squat anyway, we could bare-bones the markup too. No fancy buttons or bars, for example.
One way to look at this is: it might be good to have access to different markup strategies based on execution context. IOW, the Strategy, or a Strategy-like design; TL;DR: at runtime, pick from available interchangeable markup generating implementations.
I just tried this on Opera Mini V.6 via this emulator and and it works. http://www.opera.com/mobile/demo/
I notice that Opera Mini V6 isn't listed yet in our device support grid http://jquerymobile.com/gbs/
Looks like they just updated that emulator to run 6. It does seem to work better on the scrolling front but the back button and history doesn't seem to work right and dialogs don't dismiss correctly.
I just re-tested this on Opera Mini 5 on iOS and the navigation is also messed up but I'm not seing the scroll issue but it could be because the navigation is so broken all of a sudden. Once you hit the back button, you go back to the right page but any subsequent link forward brings you back to the previous page so navigation is effectively broken after a back.
Steven - what phone do you have for testing? I think you can get mini 5 for most platforms. I have no idea if 6 is even out, but I bet 4 and 5 will be pretty widely used for a while. I agree that we need to update the GBS to add in these new versions of mini, once we get it working.
Steven re: the fact that the blank pages are probably caused by the server cutting off rendering at a certain time, I totally agree and think that is the root issue in many cases. I wonder if the simplest thing would be to nix Ajax navigation on mini. That would probably solve the blank and cutoff pages and the back button flakiness I'm seeing.
Scott/Kin/Bender - thoughts on whether we should look for a way to opt Opera mini out of Ajax mode?
Disabled ajax navigation in BlackBerry 5 and Opera Mini, for a more u…
…sable overall experience (and in some cases, due to insufficient native history implementations that don't track hash changes). Fixes #1644 and Fixes #1276