Skip to content
This repository

Fixed toolbars change position when navigating between tabs. #4259

Open
balshamali opened this Issue · 25 comments

8 participants

balshamali Jasper de Groot Maurice Gottlieb Boris Dutkin Alexander Schmitz Mat Marquis Todd Parker Scott Jehl
balshamali

Ive been using the fixed toolbar lately and its great, in most scenarios. However, there is a bug that Ive spent two days trying to figure out and finally found a workaround for the issue.

The testing was done on ios v5 iphone emulator and does not happen by testing in chrome. The fixed toolbar is not quite fixed when navigating between pages using a navbar in the footer. The fixed toolbar changes position if you are on one page, click on the top of the screen to auto-scroll to the top of safari (note this will show the address bar), navigate to another page that is not full (as in the content of the page does not occupy the page height). The footer will rise from the bottom in an amount equal to the height of the address bar. It can be set back to the fixed bottom position by scrolling. I tried to trigger a scroll event every time I switch pages but that doesn't seem to fix the issue.

The workaround i have now is that I have modified the line:

$el.closest( ".ui-page" ).css( "padding-" + ( header ? "top" : "bottom" ), $el.outerHeight() );

in updatePagePadding function in fixedtoolbar implementation to always add enough padding to the bottom to fill the screen enough to push the footer to the bottom of the page. Any feedback would be great. Thanks

Jasper de Groot
Collaborator

@balshamali

Can you test your project using this code:

CSS: http://ugomobi.github.com/fixedtoolbars/css_new06132012.css
JS: http://ugomobi.github.com/fixedtoolbars/js_new06132012.js

This includes the changes of PR #4260 from @MauriceG

Please confirm if this solves the issues you were having with updatePagePadding. Thanks!

balshamali
balshamali
Jasper de Groot
Collaborator

@balshamali

We need a simple JSBin test page that reproduces the issue for you (on the emulator) and then we test on real device to see if it also happens there.
You can find our JSBin template here https://github.com/jquery/jquery-mobile#issues

balshamali
Maurice Gottlieb

Hi @balshamali
I've a fiddle here with listview and iOS test inputs: http://jsfiddle.net/MauriceG/Tm3Bx/
fullscreen: http://jsfiddle.net/MauriceG/Tm3Bx/show/

balshamali
Jasper de Groot
Collaborator

@balshamali

You can change anything you want in the JSBin template so it meets your actual use case and reproduces the issue. Same goes for the JSFiddle from @MauriceG. You can clone/fork it and save new version. Just don't change the source of the css and js so it keeps loading latest code.

BTW - Based on "the fixed toolbar will rise by the amount of the addressbar" I don't think it is related to the "updatePagePadding" function

balshamali
Jasper de Groot
Collaborator

@balshamali

I understand the issue is described by #4259 because the emails you receive and send about this are in fact comments added to the thread there :-)

We hoped your issue would be fixed by PR 4260, but - as you noticed - that is not the case. That PR fixed issues with the "updatePagePadding" function and after I looked into your issue again I concluded it is not related to that function.

Position fixed means fixed to the viewport. The address bar is part of the window, but not the viewport. See also section 4 here http://developer.apple.com/library/ios/#technotes/tn2010/tn2262/_index.html
That is why "the fixed toolbar will rise by the amount of the addressbar" sounds like the position of the fixed header is not updated when the viewport changes.

Looking forward to your test page so we are sure that we are looking at the exact same use case!

balshamali
balshamali

Reproduction steps:
1. Start at the first page with the iOS simulator, click on the top toolbar to scroll to the top
of the page.
2. Click on the second navbar to go to the second page.
3. Click on the top toolbar to scroll to the top of the second page.
4. Click on the first navbar to go to the first page (the fixed toolbar
will rise by the amount of the address bar).

Jasper de Groot
Collaborator

@balshamali

We will test http://jsbin.com/amalez/2/ on a real iPhone running iOS5.

Does "second navbar" and "first navbar" mean we actually have to click the link to page 2 in the second (footer) and to page 1 in the first (header) navbar?

balshamali

Correct.. first navbar means clicking on page1 and second navbar means clicking on page2.
I've tested on iphone v5.1.1 and uploaded a pic 'iphone_v5.1.1.png' here.

Maurice Gottlieb

@uGoMobi Hi Jasper!
Tested with 4S iOS 5.1: Going the way described above, it looks ok.

But doing the same with page 3 (flip transition), the footer stays like at the screenshot above until the screen is tapped.
Also going to page 3, tapping the iPhone toolbar (address bar comes in and move the page downwards) then using the fade to page 1 button, page 1 is shown correct for a short moment, but when transition is complete, the footer jumps to the position you can see at the screenshot above.

Jasper de Groot
Collaborator

@MauriceG - Hi Maurice, Thanks for testing this!

I just noticed then when you navigate from page 3 back to page 1 using the navbar button (flip transition) the footer rises 1px during the transition. (Edit: this was on Safari desktop)

Boris Dutkin

Dear uGoMobi, again thank you for a quick response! :-)
I am using a "flip" transition...I did test the same code with "fade" transition and it is seems working fine.
I have tested the page you given me: http://jsbin.com/amalez/2/ ...and I have the same "jumping" issue...(only footer)
I will try later to check the commets above about the issue...

Jasper de Groot
Collaborator

Although this is comment is added to an issue with PhoneGap I do see some similarity: #4024 (comment)

Alexander Schmitz
Collaborator

going to look into this one at summit

Alexander Schmitz
Collaborator

I am unable to confirm original issue with latest code at test page at http://jsbin.com/amalez/2 on iphone4 with ios 5.1 following steps to reproduce. will look into issue with footer jumping durring transition.

Alexander Schmitz
Collaborator

For the jumping footer during transition setting the page to position:fixed; bottom:0; fixes this. Tested on blackberry 10 native, jellybean on nexus 7, ics native, ics chrome, blackberry playbook 2.10, iphone4 ios5.1 ipad2 ios5.1. no change except on ios where the issue is fixed. test page at www.jsbin.com/amalez/37 has lots of form elements on page / in footers.

Mat Marquis

I wouldn’t believe it if I hadn’t seen it with my own eyes. Flagging this as “in review” for further investigation; looks solid so far.

Todd Parker

Yeah, it's looking like we can close this, but I'll let you all do the honors. Rock solid on iOS6 anyway.

Mat Marquis

@arschmitz and I are gonna work this fix into a branch. We’re using position: fixed here, so I wanna make sure we’re qualifying it.

Alexander Schmitz arschmitz referenced this issue from a commit in arschmitz/jquery-mobile
Alexander Schmitz arschmitz FixedToolbar: Added extension with browser specific workarounds Fixed:
…#3748 Android 2.x: Page transitions broken when fixed toolbars used


#4113 Header and footer change their position after keyboard popup - iOS
#4250 Persistent footer instability in v1.1 with long select lists in Android 2.3.3
#4259 Fixed toolbars change position when navigating between tabs.
#4337 Fixed header problem after scrolling content on iOS and Android
##4410 Footer navbar moves up when clicking on a textbox in an Android environment
948eeaa
Alexander Schmitz
Collaborator

@wilto sadly it seems as tends to be the case this was too good to be true. after more testing this does not work not sure what we were seeing at the summit but this is a no go. It seems to be related to our use of silentscroll and the bug with position:fixed and programmatic scroll. This is because another facet of this bug is that enabling hardware acceleration will cause the fixed toolbars to show in their actual position. Im looking into a workaround for this along the same lines that we solved the programmatic scroll bug.

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.