Fixed toolbars change position when navigating between tabs. #4259

Closed
balshamali opened this Issue May 1, 2012 · 45 comments
@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

@scottjehl scottjehl was assigned May 13, 2012
@jaspermdegroot
jQuery Foundation member

@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
@jaspermdegroot
jQuery Foundation member

@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
@MauriceG

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
@jaspermdegroot
jQuery Foundation member

@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
@jaspermdegroot
jQuery Foundation member

@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).

@jaspermdegroot
jQuery Foundation member

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

@MauriceG

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

@jaspermdegroot
jQuery Foundation member

@MauriceG - Hi Maurice, Thanks for testing this!

I just noticed that 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)

@BorisDutkin

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

@jaspermdegroot
jQuery Foundation member

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

@arschmitz
jQuery Foundation member

going to look into this one at summit

@arschmitz
jQuery Foundation member

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.

@arschmitz
jQuery Foundation member

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.

@Wilto

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.

@toddparker

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

@Wilto

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

@Wilto Wilto was assigned Oct 25, 2012
@arschmitz arschmitz added a commit to arschmitz/jquery-mobile that referenced this issue Nov 1, 2012
@arschmitz 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
@arschmitz
jQuery Foundation member

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

@gabrielschulhof

http://jsbin.com/buqufa/1/ updated to the latest code.

@gabrielschulhof

I believe this is fixed now, but we should test on multiple devices.

@gabrielschulhof gabrielschulhof added this to the 1.5.0 milestone Jan 29, 2015
@gabrielschulhof

In http://jsbin.com/buqufa/1/ I've slowed down the turn transition, because it looks like, when going from page3 to page1, although the final state is correct, during the transition the footer is still off by an address bar's height. Interestingly this does not happen with the fade transition.

@gabrielschulhof

To see the effect:

  1. Go to page 3
  2. Click on the link "Page 1" located in the header

At this point, page 1 toolbars appear immediately, and the transition seems to affect only the contents, and the footer is offset.

@gabrielschulhof

Doing external fixed toolbars does not improve things: http://jsbin.com/buqufa/6/

@gabrielschulhof

So, I would conclude that, yes, it's fixed, but the turn transition could use some improvement.

@gabrielschulhof

The flip transition has the same problem: http://jsbin.com/buqufa/7/

@gabrielschulhof

All these are tested using BrowserStack/iPhone 4S (iOS5.1), BTW.

@gabrielschulhof

iOS 6 is similarly broken for non-slide transitions. iOS 7 is better, but there's still an offset during the transition.

@gabrielschulhof

iOS 8 has no offsets, but the toolbars blink before the transition starts.

@gabrielschulhof

You get an offset in Chrome Version 39.0.2171.95 (64-bit)/Linux as well.

@gabrielschulhof

I've removed "Platform: iOS" because it's not just iOS.

@gabrielschulhof

FF also has the 1px jump.

@gabrielschulhof

Here's a quick summary of all transitions: http://jsbin.com/fujuhe/3/

@gabrielschulhof

Transition status (iOS 6 - actual device):

  • ✓Fade
  • ✗Flip
  • ✓Flow (but footer flashes)
  • ✓Pop
  • ?(Maybe) Slidedown (footer may be flashing or may be offset - can't tell)
  • ✓Slidefade
  • ✓Slide
  • ✓Slideup
  • ✗Turn

OK, I guess this is not so bad ... OTOH, maybe they're all (except slide) broken, but except for turn and flip the others are not so resource-intensive as to break the display.

@gabrielschulhof

Same status for Chrome/desktop, except there's no flashing. I'd say flip and turn are broken.

@gabrielschulhof

Interestingly, only flip and turn have classes viewport-flip and viewport-turn defined in the CSS.

@jaspermdegroot jaspermdegroot self-assigned this Jan 29, 2015
@gabrielschulhof

OK, "broken" may be a strong word - I mean, the one-pixel shift can only be seen in those transitions AFAICT.

@jaspermdegroot
jQuery Foundation member

I have to look into this issue again and read all the comments but I think the cause is the same as what I described here #8264 (comment)

@jaspermdegroot jaspermdegroot removed this from the 1.5.0 milestone Aug 19, 2015
@apsdehal
jQuery Foundation member

No longer supported.

@apsdehal apsdehal closed this Jul 7, 2016
@apsdehal apsdehal assigned apsdehal and unassigned jaspermdegroot Aug 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment