jquery/jquery-mobile — pull request #4260 by MauriceG (2012-05-01 18:39:34+00:00)
Title: Suggestion: Fix for fixed persistent toolbar padding issues

Tested with Safari 5.0.5 on Windows, 5.1.5 on MacOS, iOS 5.1 on iPhone4 + iPad3, Chrome 15.0 + 18.0 on Win, FF 9.0.1 + 12.0 on Win, Opera 11.52 on Win, IE7, Android 2.2.1 on Archos 70 tablet

May it's superfluous here to outline how the fixed toolbar bindings behave, but it shows why the current code cannot work if the ```updatePagePadding``` option is true and the header and/or footer are higher than a standard toolbar.

Note: The ```updatePagePadding()``` function always searches its closest ```.ui-page``` container to calculate the necessary page-padding.

When showing the initial page, the ```pageshow``` event calls ```updatePagePadding()``` and everything works fine.

When a page navigation occurs the following happens in this order (please correct me if I'm wrong):

```pagebeforehide``` searches the fixed toolbar/s of **page-to** and *moves* them to ```$.mobile.pageContainer```. Then another ```pageshow``` event is bound to the page-to, which will move the toolbar/s to that to-page.

The bound ```animationstart``` event fires on the page-from and calculates the page-padding of the page that will be left now...

The bound ```animationstart``` event fires on the page-to and calls ```updatePagePadding()``` to set the padding. But, page-to has no toolbars at this moment. They're still in the ```$.mobile.pageContainer```. The paddng could not be calculated.

The bound ```pageshow``` event fires on the page-to and do the same again. Still no toolbars in the page.

The second ```pageshow``` event (bound at ```pagebeforehide``` in one of the steps above) fires and moves the toolbar/s from the page-container to the page-to. Too late.

The next navigation will set the proper padding to the page cause of the out-transition. When this page is shown again, the padding will be ok.

I hope my deliberations were not too boring.