Fixed toolbars change position when navigating between tabs.

[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

[jaspermdegroot]

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

Sure I will let you know shortly.

On Thu, Jun 14, 2012 at 6:45 PM, Jasper de Groot <
reply@reply.github.com

wrote:

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

---

Reply to this email directly or view it on GitHub:
#4259 (comment)

[balshamali]

Unfortunately this still happens with the new files you provided. Ive added
a screenshot of the issue.

On Thu, Jun 14, 2012 at 9:02 PM, Bassam Al Shamali biscim@gmail.com wrote:

Sure I will let you know shortly.

On Thu, Jun 14, 2012 at 6:45 PM, Jasper de Groot <
reply@reply.github.com

wrote:

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

---

Reply to this email directly or view it on GitHub:
#4259 (comment)

[jaspermdegroot]

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

Can the content within the JSBin page change. For example, can I add a
listview because it seems to happen when i have that container. Also there
are other issues such as the footer partially hiding when clicking on the
page (it should completely hide).

On Fri, Jun 15, 2012 at 4:52 AM, Jasper de Groot <
reply@reply.github.com

wrote:

@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

---

Reply to this email directly or view it on GitHub:
#4259 (comment)

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

Steps to replicate:

1. Have two pages that are not full (since if they are completely full then
   you will always push the footer to the bottom of the page).
2. Start at the first page, click on the top toolbar to scroll to the top
   of the page (with an ios simulator).
3. Click on the second navbar to go to the second page.
4. Click on the top toolbar to scroll to the top of the second page.
5. Click on the first navbar to go to the first page (the fixed toolbar
   will rise by the amount of the addressbar).

I will upload an example sometime soon to show this behavior using the
JSBin template you have.

On Fri, Jun 15, 2012 at 10:21 AM, Maurice Gottlieb <
reply@reply.github.com

wrote:

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

---

Reply to this email directly or view it on GitHub:
#4259 (comment)

[jaspermdegroot]

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

The problem I am talking about it summarized by:
#4259

and I assumed it was being fixed by the fix provided in:
#4260

Am I confused?

On Sat, Jun 16, 2012 at 4:40 AM, Jasper de Groot <
reply@reply.github.com

wrote:

@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

---

Reply to this email directly or view it on GitHub:
#4259 (comment)

[jaspermdegroot]

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

I understand they get posted there but I was just clarifying what we were
talking about because it seems that the issues were getting confused.
Please take a look at the test page:

http://dropcanvas.com/todr0

On Sat, Jun 16, 2012 at 9:00 AM, Jasper de Groot <
reply@reply.github.com

wrote:

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

---

Reply to this email directly or view it on GitHub:
#4259 (comment)

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

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

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

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

[arschmitz]

going to look into this one at summit

[arschmitz]

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]

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.

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

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.

[gabrielschulhof]

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

[jaspermdegroot]

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)

[apsdehal]

No longer supported.