Switch fixed toolbars to CSS position:fixed

[toddparker]

Issue #1792 was originally opened to move away from the dynamically positioned (via JS) toolbars to use position:fixed but at the time, we decided to pursue the touchOverflow approach because it made fixed toolbars and smoother transitions happen, if only in iOS5 for now.

Brad Frost recently did a fresh batch of testing and re-thinking the use of native position:fixed is warranted because not only does it give us "true" fixed toolbars with minimal code, it is surprisingly well supported and mostly falls back to inline positioning. The worst case scenario is that in some browsers (BB6, Android 2.1), the toolbars scroll with the page before re-positioning themselves but this isn't much different than our current JS-based solution.

Brad's results: http://bradfrostweb.com/blog/mobile/fixed-position/

Our testing of his pages for both position:fixed and overflow: https://github.com/jquery/jquery-mobile/wiki/Position:fixed-and-Overflow:-testing

Native overflow is more difficult to use for two reasons: on some browsers, overflow content is clipped off and inaccessible or requires a two finger scroll, and even when it works, performance can be slow.

If we switch to using position:fixed, we would need to disable user zoom to make this kick in for Android. It also makes it a bit easier to use across the board because it's easy to get into odd zoom scenarios where the fixed toolbars take up the whole screen and other usability issues. This is a case where the tradeoffs seems acceptable if you opt into fixed toolbars.

We expect to have true fixed toolbars working on following platforms:

• iOS 5
• Android 2.2, 2.3, 3.0 (honeycomb), 4.0 (Ice cream sandwich)
• Blackberry 7 (BB6 re-positions fixed after scroll stops, like our JS solution)
• PlayBook
• Firefox mobile 6
• WebOS 2+
• Kindle Fire
• Kindle 3
• Nook Color 1 & 2 (tablet)
• All modern desktop browsers (Safari, Firefox, Opera, Chrome, IE, etc.)

Most other platforms will simply fall back to inline positioning. There are a few platforms that may half-support this feature and may incorrectly position the toolbars so we'll need to keep an eye out to see if we need to manually exclude these if they aren't usable:

• Android 2.1
• Blackberry 5
• Opera Mobile

A few technical things to keep in mind:

• Since the fixed toolbars will be absolutely positioned, we need to account for the height of the toolbars and add equivalent top/bottom margins on the content area to keep the content from being obscured by the toolbars in normal fixed mode (fullscreen mode does this intentionally).
• We might also want to set a minimum screen height to use this feature because some Blackberries have small screens and toolbars could take up more that 50% of the height. If could be a simple rule that we don't active this unless the total height of fixed headers and footers are less than % of the height.
• We will also keep the option to tap the screen to switch between fixed and inline toolbars, like the current fixed demo illustrates. Fullscreen toolbars actually tap to hide/show the toolbars.
• We might want to add in an option to either show by default, hide by default or show initially but hide after X seconds.

[toddparker]

This is being worked on by @garann in the dialog refactor branch right now, looking promising.

[scottjehl]

Will we still include JS to control the logic for tap-toggling the visibility of the toolbars?

To my memory, this behavior constituted a large portion of this plugin's logic, and was unrelated to the absolute positioning part (which I agree sounds fine as position: fixed, assuming it doesn't fall apart in any popular fixed-unsupporting browsers).

Thx!

On Dec 5, 2011, at 9:19 AM, Todd Parker wrote:

Issue #1792 was originally opened to move away from the dynamically positioned (via JS) toolbars to use position:fixed but at the time, we decided to pursue the touchOverflow approach because it made fixed toolbars and smoother transitions happen, if only in iOS5 for now.

Brad Frost recently did a fresh batch of testing and re-thinking the use of native position:fixed is warranted because not only does it give us "true" fixed toolbars with minimal code, it is surprisingly well supported and mostly falls back to inline positioning. The worst case scenario is that in some browsers (BB6, Android 2.1), the toolbars scroll with the page before re-positioning themselves but this isn't much different than our current JS-based solution.

---

Reply to this email directly or view it on GitHub: https://github.com/jquery/jquery-mobile/issues/3216

[toddparker]

The plan is to keep the tap to toggle so it would go from fixed to inline, like it does today. Garann and I were talking an hour ago in irc about the details.

Since fixed is pos:absolute, we need to measure the height of headers and footers and add that as a top/bottom margin on the content block to keep proper spacing.

Think that whole plugin could be simplified with this change.

[toddparker]

I was actually thinking we might want to automatically shut off fixed toolbars if they are more than 40-50% of the screen heights on these don't suck on small screens.

[scottjehl]

Sounds great - that was all I wondered about it. :)

On Dec 5, 2011, at 12:43 PM, Todd Parker wrote:

I was actually thinking we might want to automatically shut off fixed toolbars if they are more than 40-50% of the screen height son these don't suck on small screens.

.................................. . . . . Todd Parker Partner, Filament Group Inc. 102 South Street #3 Boston, MA 02111 todd@filamentgroup.com // 617.953.1617

On Dec 4, 2011, at 8:46 PM, "Scott Jehl" reply@reply.github.com wrote:

Will we still include JS to control the logic for tap-toggling the visibility of the toolbars?

To my memory, this behavior constituted a large portion of this plugin's logic, and was unrelated to the absolute positioning part (which I agree sounds fine as position: fixed, assuming it doesn't fall apart in any popular fixed-unsupporting browsers).

Thx!

On Dec 5, 2011, at 9:19 AM, Todd Parker wrote:

Issue #1792 was originally opened to move away from the dynamically positioned (via JS) toolbars to use position:fixed but at the time, we decided to pursue the touchOverflow approach because it made fixed toolbars and smoother transitions happen, if only in iOS5 for now.

Brad Frost recently did a fresh batch of testing and re-thinking the use of native position:fixed is warranted because not only does it give us "true" fixed toolbars with minimal code, it is surprisingly well supported and mostly falls back to inline positioning. The worst case scenario is that in some browsers (BB6, Android 2.1), the toolbars scroll with the page before re-positioning themselves but this isn't much different than our current JS-based solution.

---

Reply to this email directly or view it on GitHub: https://github.com/jquery/jquery-mobile/issues/3216

---

Reply to this email directly or view it on GitHub: https://github.com/jquery/jquery-mobile/issues/3216#issuecomment-3011275

---

Reply to this email directly or view it on GitHub: https://github.com/jquery/jquery-mobile/issues/3216#issuecomment-3011521

[woutervanwijk]

Sound good to me. The toolbars don't work very well right now, especially the fixed ones. I like the way it's implemented on the mobile site of seeekingalpha.com

[toddparker]

According to Google, this technique will work in 85-90% of Android devices as of Dec. 2011 (2.2, 2.3, 3.0): http://developer.android.com/resources/dashboard/platform-versions.html

It will be interesting to see iOS5 % vs older versions.

[toddparker]

Initial testing is very promising. We're now working on a support test to decide which browsers should get the fixed:rules. Ideally, we can write a test to opt out the handful of browsers that claim to support this, but end up incorrectly positioning the bars over the content instead of falling back to static positioning.

The current test is based on Kangax's fixed position feature test. We're going to look at adding with some tweaks based on Modernizr's test to resolve an error in IE7 with the Kangax test. http://kangax.github.com/cft/#IS_POSITION_FIXED_SUPPORTED

This test page runs our current fixed: support test and adds a row with the result for each unique UA it finds: http://filamentgroup.com/tests/fixedtest/

The most important platform caught by this test is older versions of iOS (pre-5) what incorrectly drop the toolbars over the content then scroll them with the document.

We currently have a few false positives in the Kangax test where it passes the test, but crashes and burns on positioning. We've been working on trying to detect the positioning issues to fail these browsers, but it seems like they are reporting the right values, but rendering them wrong so it may be hard/impossible to write a support test eliminate all the browsers cleanly.

The browsers that currently pass the test but fail on rendering correctly are:

• Android 2.1
• Opera Mobile (less than 11.0, 11.5 works but dynamically re-positions instead of true fixed)
• Opera Mini (latest)
• Firefox mobile (latest)

We also might want to exclude Blackberry 6 from this feature because it dynamically re-postions the toolbars when you scroll and it looks really bad. Falling back to static would be preferable in an browser that re-positions the toolbars when a :fixed rule is in play.

To see this issues with these browsers, view this link and scroll the page: http://wil.to/fixed/

[toddparker]

We had a crazy idea to try and use position:fixed to simulate overflow panels. When you touch the left panel to scroll, it clips and sets the right panel to position: fixed. We flip this when you try scrolling the right. It works in theory but is pretty buggy in practice, but worth the experiment: http://jsbin.com/ituris/65

[toddparker]

[ Here is an update from @scottjehl on his latest progress and new fixed branch ]

Okay so, first off, Mat and I wrote a pretty good feature test for position:fixed support, but unfortunately, it was pretty obtrusive (scrolling the window), and also gave inaccurate results in Android 2.1 – maybe some others too.

For these reasons, I’m now trying to build the feature to be enabled for all, and then opt-out a few troublesome browsers with brute force (read: browser detection. I know, I know…).

So, on the topic of that feature that’s enabled for all:

I just pushed a big update to the new css-fixed branch that begins work on porting the fixed toolbars feature over to CSS positioning. The branch contains a draft of a full rewrite of the fixed toolbars feature, which I think is good because there’s a lot of hard-to-understand cruft in the current one.

Here’s a list of changes in place so far:

• I removed both jquery.mobile.fixHeaderFooter.js and jquery.mobile.fixHeaderFooter.native.js and added a new file “jquery.mobile.fixedToolbars”, which contains the new behavior.
• I moved all of the CSS related to this feature to jquery.mobile.headerfooter.css file, so it no longer has remnants in Core CSS.
• In iOS5, the feature works great for me. However, I’ve removed the iOS5-specific CSS touch-overflow handling from this plugin entirely, as it’s not needed for fixed positioning to work. It’s currently just using the default browser scrolling, which is nice because the momentum feels more natural than the overflow version. However, this change would mean that the transitions jump to top again in iOS5, rather than pinning in place, but I’m planning to tackle a change to transitions next that should make that problem go away (we’ll be prototyping a different transition style next that won’t need overflow support). Anyway, transitions aside, if we want to keep overflow-scrolling support in there, we can add the feature back again to a core file, since it’s unrelated to this plugin. It’s as simple as a class addition and a few lines of CSS.
• The plugin still supports both regular fixed toolbars and “fullscreen” toolbars (which overlay content, even when scrolled to the top or bottom), though it now allows the data-fullscreen attribute to be on the header itself, in addition to the page div, which we supported before.
• When the toolbars are fixed, but not “fullscreen”, the page div has top and bottom padding to accommodate the toolbar heights that are not there. This padding amount will likely need to be dynamically updated on load, resize, and though a manual method devs can use (ugh).
• Since page zooming can cause usability issues with fixed positioned elements, I’ve wired up the plugin to disable user zoom whenever a fixed toolbar page is active, but then reset the user zoom settings to whatever configuration it was in before, after the page is hidden again. (This currently has a bug in the reset part, but you can at least see that most of the docs are zoomable, but then you can’t zoom into the fixed toolbars page).
• The new plugin is written using the widget factory, which will make for easier testing and extension points, as well as options and methods support.
• This also means that the plugin is called per-toolbar, rather than per-page. I’m seeing some great benefits to this already, both organizationally for us, and for configuration.

The following options are preliminarily supported:

• visibleOnPageShow: boolean for whether a toolbar should be visible when its page is shown
• togglePageZoom: if true, the plugin will disabled page zooming when the toolbar is visible
• transition: the transition for showing and hiding the toolbars. Currently it’s set to “fade”. “slide” also works, and slides the bars up and down from the vertical edges of the screen. This option can also be false, for no transition.
• fullscreen: boolean, formerly only a data attribute, which allows for “fullscreen” overlay toolbars
• tapToggle: tap to show and hide the toolbars. Preliminary support is in place, and enabled for testing purposes. Note that this feature probably should not work if the user is scrolled to the top of the page and the toolbars are not “fullscreen”. Otherwise it just hides and leaves whitespace, which is odd.
• scrollToggle: show and hide the toolbars during scroll. This isn’t quite working yet, and in hindsight, I should probably pull it out and replace it with an option for “hideonScrollstop, which hides the toolbars when you STOP scrolling, allowing you to bring them back again with a tap. The NYTimes iOS app does this and it’s pretty nice. The code weight would only be a few lines for that feature.
• supportBlacklist: the dreaded browser detect blacklist! So far, I’ve opted out iOS versions older than 5 (please verify), and Opera Mini. I still need to add detection for Android webkit older than 2.2. Since this is an option, people can improve it or remove it too, or try to polyfill it, which is nice. We should do some spoof-testing on this too, especially on BB!
• initSelector: defaults to‘)”, for auto-initializing. The plugin auto-inits on pagecreate and create, like most others.

The following methods are also supported:

• show: show the toolbar
• hide: hide the toolbar
• toggle: toggle the toolbar
• destroy: just for class removal so far
• disablePageZoom: the function used internally for disabling user zoom. This may be best left private, we’ll see.
• restorePageZoom: opposite of above. Again, should probably be private.

I’ve posted a demo of the branch so we can begin testing it as I work on bugs and unit tests. The tapToggle option is enabled, just for fun, but I’d imagine it’ll be off by default (yes?).

http://filamentgroup.com/tests/jqm-nativefixed/

[toddparker]

Awesome work Mr. Jehl. So far, testing has gone really well on the link above. There are two issues I've seen so far:

• The tap to toggle interferes with the select element and many other widgets. When I click the select, it toggles the toolbars instead of activating the select. On iOS 5, it toggles the toolbars then opens the select but on Android, the first tap toggles the toolbars and you need to click again to open the select.
• When you tap to hide, as you mentioned above, you end up with a blank slot. Could we just not hide a toolbar that is visible in the viewport if you're looking at this in non-fullscreen mode? Think that's how it works currently

[toddparker]

I just did a quick scan on key platforms to summarize our testing results so far:

Confirmed support = true fixed toolbars with native scrolling

• Playbook
• BB7
• Nook
• Kindle Fire
• Kindle 3 (!)
• iOS5 - iPhone and iPad
• Android Honeycomb tablets
• Android 2.2 and 2.3

Safely falls back to static positionering naturally or through current test/blacklist

• iOS 3-4
• WP 7-7.5
• Android 1.5-1.6
• Blackberry 4-5
• WebOS 1.4

Still to be excluded, impacts usability - listed by importance

• BB6 - toolbars reposition (sometimes) after scroll, but seems to impact scrolling performance
• BB5 - toolbars reposition many times during scroll so jittery, footer positioning is about 10px too high
• Android 2.1 - toolbars are positioned over the content
• Opera Mobile - version 11.5 sort of re-positions after scroll, but cleaner to exclude all versions
• Opera Mini - tested ib 6.5 (latest) but exclude all versions
• Bada Dolphin - toolbars are positioned over the content
• Firefox mobile - re-positions after scroll, could keep but it's not an ideal experience
• WebOS 3/TouchPad - re-positions after scroll, could keep but it's not an ideal experience

[commadelimited]

Thanks for all the hard work guys. I've spoken about jQuery Mobile to hundreds of people at conferences and user groups and this is one question that comes up time and time again. Thanks for making it happen.

[scottjehl]

Hey Todd, Thanks for pasting my email in. I'm glad to hear testing is going so well!

For review so far, here's the JS for the plugin: https://github.com/jquery/jquery-mobile/blob/css-fixed/js/jquery.mobile.fixedToolbar.js And the CSS: https://github.com/jquery/jquery-mobile/blob/css-fixed/css/structure/jquery.mobile.headerfooter.css

On my note about dynamically adjusting the padding above, I think it might be better to just leave it to developers to adjust the padding based on their content and toobar height. Just seems really fussy to bind to events and keep recalculating it.

[toddparker]

What if we just set padding once and then we can document how you should recac manually if you change the height of the toolbars?

Also curious whether we should use margin instead do the padding is consistent between pages using fixed and those without?

[scottjehl]

Yep - agreed on setting it once (in CSS, as it is now, ya?). Unless the toolbar has elements that reflow to change the height, once should be adequate.

re: margin: The padding is set on the page element, which normally has none. https://github.com/jquery/jquery-mobile/blob/css-fixed/css/structure/jquery.mobile.headerfooter.css#L25 Margin wouldn't be as good here, as I think we need the page to fill the dimensions of the screen.

For "fullscreen" toolbars, I've got a rule in there that removes all padding on the content div, under the assumption that people would use this feature mostly for full-screen photos and such. It's easy enough to override that if you need different padding though.

[toddparker]

Agreed that setting it once is good enough. Though I think we need to use JS to measure and set the padding based on the actual toolbar height since that could be quite variable. That what you had in mind? We could then offer a way to trigger a re-calc programmatically.

Setting the padding on the page is a great idea, same effect as margin on content but better. I just wanted to leave padding in content area alone so we're good.

Yep, full screen should work as described. I was just saying that we could not hide a normal fixed toolbar if you tap and you're at the top/bottom to avoid the blank space.

[negue]

Great!

True Fixed Toolbars works on Samsung Galaxy Tab (Android 2.2)

But the z-index of the Switch-Control is higher than the Toolbars.

[woutervanwijk]

This is much better on iOS5 iphone and pad! Great! Two (small) problems: same here with the z-index of the switch control, and when switching from landscape to portrait and back, the toolbars are only half visible. Except from that a much better user experience already.

[toddparker]

I just updated the demo on our site with the latest version of the fixed toolbars from the css-fixed branch: http://filamentgroup.com/tests/jqm-nativefixed/

[woutervanwijk]

It works great on firefox and chrome (most recent non-beta versions), but only until I focus on one of the form-controls in the page. After that, the toolbars disappear suddenly and get out of position.

[toddparker]

Yeah, we're still refining how to not hide the toolbars when interacting with widgets vs. tapping the page.

[rbdcti]

Hey guys, looking forward to true fixed toolbars under iOS 5, et al, however both the current css-fixed branch with my app and the demo at http://filamentgroup.com/tests/jqm-nativefixed/ (fixed toolbars page, obviously) do not gracefully degrade on my iPhone 4 running iOS 4.3.1. I am seeing the footer all the way down at the bottom of the page, not 'hovering' like the current JQM mainline behavior (i.e. you have to scroll all the way down to see it)...just wanted to make sure you know about this. I can provide more info/screenshots as necessary.

(I was going to go with the css-fixed branch and manually port over the fix from pull request #3050 for the degraded toolbar code, but I noticed all that logic was gone, as Todd said above.)

[scottjehl]

Hey rbdrbd, Thanks for the feedback. Actually, what you've described is the behavior we're aiming for, as iOS5's share is increasing steadily. Our aim is to try and support true fixed positioning, and let browsers that can't support it (like ios4) degrade to statically positioned toolbars at the top and bottom of the document, rather than the screen. Some browsers like ios4 get it halfway-right, or half-wrong really, so we're manually kicking them out to avoid usability issues.

The way the new plugin is written will make it easy to polyfill the support in devices like ios4 more easily, or at least to the level that we support it in master now, which uses fade-in and fade-out to hide during scroll.

[scottjehl]

Hi Todd and everyone. There are some updates in the CSS-Fixed branch that could use some device testing. Some known-misbehaving browsers are opted out now: iOS<5, Android Webkit < 2.2, Opera Mini, Fennec < 6, and WebOS < 3. Also, touch overflow support is back in again using the same API, though it's now part of core instead of being tied to the fixedtoolbars plugin. It's false by default and could use some iOS5 testing for odd behavior.

Today's commits https://github.com/jquery/jquery-mobile/commits/css-fixed

Thanks!

[rbdcti]

scottjehl: Thanks for that great info. That makes sense. I notice you did say "let browsers that can't support it (like ios4) degrade to statically positioned toolbars at the top and bottom of the document, rather than the screen". Does this mean that even if my markup has only a persistent footer toolbar, when and if it's viewed on an iOS v4 (etc) type device, JQM will automatically add a statically positioned toolbar under the header bar that is the same as the statically positioned toolbar at the bottom of the document? So I'd get this behavior for free basically in that case?

I'm asking because I didn't see this automatic header behavior on the css-fixed build I tried. I did notice you made a number of updates a few days ago, so I can try again if you added this. Also, is there a page content length threshold that determines if this header is shown (e.g. don't show it if all the content fits on the display)?

P.S. - If we're degrading to statically positioned toolbars, I do like that behavior the best. It would be a major usability issue to not have the header, especially on very long pages.

[toddparker]

@rbdrbd - In browsers that don't support :fixed, the toolbars will just fall back to being in the document flow (static) so a header will be first, then the content, then the footer - all will scroll with the document. Imagine the page without the fixed data attribute. Think we're doing what you prefer :)

[toddparker]

Test results with the latest "css-fixed" branch code. The tap to hide isn't quite working right now (hides, then shows right away & z-index incorrect after toggle) and we might want to add in a fallback to static is the height of the fixed toolbars are more than X% of the screen height to keep this from taking over a small screen device.

Android 2.1 - Now excluded from fixed: rules, toolbars now safely fall back static positioning Android 2.3 - True fixed toolbars Kindle Fire - True fixed toolbars Honeycomb 3.0 - True fixed toolbars iOS4 - Toolbars safely fall back static positioning iOS5 - True fixed toolbars, tap to toggle works on the footer and both bars on the fullscreen page BB7 - True fixed toolbars but the toolbars take up 40+% of the height of the Curve - is static better? BB5/6 - Bars scroll with page and re-position after scroll stop but functional WebOS 1.4 - Toolbars safely fall back to static positioning Firefox Mobile 9 + 10 beta - Not true fixed, bars scroll with page and re-position after scroll stop but functional Older Firefox mobile - falls back to static positioning (manually exclude older than version 6) Opera Mini - Excluded, falls back to static positioning Opera Mobile 11.5 - Bars scroll with page and re-position after scroll stop but functional Dolphin 7.2.1 (Bada) - True fixed toolbars UC Web - Toolbars safely fall back static positioning

[toddparker]

Please help us test on other browsers and report unique results here.

[staabm]

to help you testing different git branches than "master" it would be cool if all github branches would be synced with httü://jquerymobile.com/test (maybe a subfolder for each branch?).

[lhwparis]

you are not testing windowsPhone 7.5? i thought its a jqm a-grade system?

[scottjehl]

Windows phone will need testing, yes - both pre and post Mango :)

[scottjehl]

Todd - great test results! Thanks. I agree about opting out conditionally based on window or screen size - I guess we'll also need to do that on resize and orientation change too...? Always more complicated than it seems.. :)

For your note on iOS5 only toggling the footers - are you sure that wasn't only when you were at the top of the page? The expected behavior for the "fixed" (not fullscreen) toolbars is to only toggle a toolbar if it is positioned away from its static resting place... otherwise you'll just see it hide with blank space behind it. So if you are at the top of the page, the expected behavior (at least in the way I built it so far) is for the footer to hide, but the header to stay visible. The opposite would happen when scrolled to the very bottom. Anywhere in between, both should toggle.

Can you confirm this is what you're seeing?

[lhwparis]

why are you not skipping support for pre-mango? 100% of devices got the mango update and the mobile ie9 is a great step ahead. so why spend time to optimize jqm for very few users not updating there device for any reason?

[scottjehl]

Well, I think we should just test around and see how things fair is all. Also, we still do support IE7 and up, which is essentially the same as pre-mango. I want to make sure we aren't introducing any usability issues mostly.

[toddparker]

WP7 is A grade but now I wonder if we need A+ grade for things like fixed toolbar and overflow support. These are nice to have features that we layer on top of the A grade experience.

[lhwparis]

Dont think A+ grade is needed. i think a-grad says: all features are working. so fixed toolbars should work in all a-grade browsers it does not matter they are fixed positioned or fixed by js-hack.

[toddparker]

@scottjehl Just re-tested and you're right on the hiding - it's working as expected. On opting out based on size, thinking this could just be a simple test on initial page create that just ensures that these don't make the page unusable. The scenario I'm thinking of is a fixed header and tall iOS style footer which would use the majority of the height on a bb curve.

@lhwparis I was sort of kidding by A+but there will be some features that will work even better than others within grade A. In the case of fixed toolbars, my thought right now is that we won't include the poly fill to dynamically reposition them by default because the result isn't that good and it takes quite a bit of code. I think it's a better experience to fall back to static toolbars that scroll with the page but we can look at how to offer the old poky fill behavior as an optional plugin if you really need that in iOS4.

Oh, and I wasn't thoroughly testing this in WP7/7.5 because early tests showed this simply rendered as static. Most of the effort has been to find misbehaving browsers and figure out how to exclude them.

[lhwparis]

@toddparker thanks for your answer. yes IE9 mobile renders fixed position as static like iOS4 does:( dont know why:( hope MS will change this. fixed toolbars give your mobile-website much more "app-like" behavior especially when you use jqm within phonegap so i hope you find a way (especially for ie9 mobile) to implement it with JS without a massive performance drop.

[brunnsbe]

I tested the code found on http://jquerymobile.com/branches/css-fixed/docs/toolbars/bars-fixed.html on Nokia N9 (Meego 1.2, built-in browser, release PR 1.1) and it behaves a bit weird. After the page has loaded the fixed footer is shown at the bottom of the screen (not at the bottom of the page). When I scroll the page the footer is fixed at its original position, so it doesn't get fixed to the bottom of the screen. Tapping the screen hides the fixed footer but instead show it at the bottom of the page and also the other way around (tap it to show it again and it disappears from the bottom of the page).

[barbalex]

Hi I just tested the version from here: http://jquerymobile.com/branches/css-fixed/js/  and here: http://jquerymobile.com/branches/css-fixed/css/themes/default/  on my new google nexus on my own app (http://barbalex.iriscouch.com/evab/_design/evab/index.html). These are the results: Android's own browser: Yeah, this is what it should be like. Rock solid headers and footers. Glorious. Beautiful. Thanks guys! Opera mobile and Firefox, both newest version: Less glorious. Fixed footer and header scroll with the page and position again when scrolling ends. And on my PC: Chrome, Firefox (both newest versions), IE9: Rock solid headers and footers.

Uups. Just noticed that often a part of the body on the top is now hidden behind the header. This part is probably about as high as the fixed footer. This happens under these conditions:

• List views: always (the search filter field is nearly hidden)
• Forms: When the window is wide enough for the label to be placed to the left of the input element

Also, when I focus a input the footer disappears. When I focus the next input it reappears. And so on and on.

Tested on Chrome and Firefox, newest versions. Alex

[abhipanda]

There seems to be an issue in the latest build when tapping. On tap the footer hides but on scrolling it reappears and comes to middle of the screen.

http://code.jquery.com/mobile/latest/demos/docs/toolbars/bars-fixed.html

Tested in Chrome.

[dcarrith]

I've encountered a few issues with the new fixed position code. @barbalex and @AbhinandanPanda have mentioned some of them.

1.) The tap to toggle is also triggered when clicking buttons on pages (or LI items, etc) with fixed headers/footers (I suppose it's just when you click on anything since @barbalex mentioned that it happens when trying to focus on form inputs too).

2.) Sometimes the fixed header will toggle, then it's just gone (i.e. if I scroll back up to the top, it isn't inline at the top as it should be). At that point, the only way to get the header back is to scroll down enough for it to be toggled on a click and then click to toggle.

3.) I know this has been mentioned in the 3217 thread, and I'm not sure if it could have been caused by the fixed position changes, but maybe. I have two buttons in a data-role="header" role="banner" div that were showing up fine before I pulled down the latest code to test this fixed position issue.

The first issue deals with buttons with only text in them (no icons). The ellipses truncation is cutting text off sooner than it did in the official 1.0 release. Noticed on a couple devices running some form of Gingerbread then Tested on Chrome, Safari and Firefox running on OSX. It seems that it's just an issue caused by a change to when that ellipses truncation kicks in. On the browsers running on OSX, I have to set the width to somewhere between 692 and 696 or so to get a six and seven letter words to show fully. There should be plenty of space even when rendering on a mobile phone browser. Two buttons in the same row are allotted 28% each (total 56%) of the width of the page.

The other issue is with two buttons that are on a fixed position footer. The two buttons only have an up and down arrow icon in them. For some reason, the width of the button is rendering much more narrow than it used to. So, it's not wide enough to show the whole 16px wide up and down arrows. Those are the only two things on the footer. With the official 1.0 release, I could have the space allocated for the two buttons at a 10% width of the page. After pulling down to test the fixed position code, I have to give them about 25% of the width of the page in order for them to render properly. Certainly 10% should be enough for rendering a little button with a 16-24px button on it.

[abhipanda]

I am a big fan of this project and would like to contribute with whatever I can. No offence but in my opinion the whole tap to toggle visibility is a "nice to have feature" but not a "must to have feature". If this feature is causing issues, I think we should reconsider postponing to future releases as developers like me will be more than happy just to have an option to make the footer fixed or relative without any glitches.

[agcolom]

@toddparker @scottjehl When testing http://jquerymobile.com/branches/css-fixed/docs/toolbars/bars-fixed.html on FF 8.0.1 (Mac OS) and Safari 5.1.1

All works fine, but there is a minor bug: Scroll down a bit so that you still have some of the "secondary display" menu on the left handside, and so that the header bar is over the menu. click the window to toggle the fixed bars. The header and footer bars disappear from the screen. Scroll to the top of the screen (the header bar is right at the top as expected). Now, click the window again to toggle the fixed bars. Slowly scroll down. You'll see that the secondary display (left hand0side menu) goes over the header bar, and the form elements also go over the bar.

Problem: It seems that the toggle in this case gives the header bar the fade.out class (and the z-index of 0 associated), and loses its z-index of 1000.

 .fade.out {
     z-index: 0;
 }

(I hope I was testing the correct file here... )

Anne

[scottjehl]

Nice catch, Anne!

Any z-index values in transitions can now be removed, as we no longer stack pages during transitions.

On Jan 23, 2012, at 5:56 AM, Anne-Gaelle Colom wrote:

@toddparker @scottjehl When testing http://jquerymobile.com/branches/css-fixed/docs/toolbars/bars-fixed.html on FF 8.0.1 (Mac OS) and Safari 5.1.1

All works fine, but there is a minor bug: Scroll down a bit so that you still have some of the "secondary display" menu on the left handside, and so that the header bar is over the menu. click the window to toggle the fixed bars. The header and footer bars disappear from the screen. Scroll to the top of the screen (the header bar is right at the top as expected). Now, click the window again to toggle the fixed bars. Slowly scroll down. You'll see that the secondary display (left hand0side menu) goes over the header bar, and the form elements also go over the bar.

Problem: It seems that the toggle in this case gives the header bar the fade.out class (and the z-index of 0 associated), and loses its z-index of 1000.

.fade.out {
    z-index: 0;
}

(I hope I was testing the correct file here... )

Anne

---

Reply to this email directly or view it on GitHub: https://github.com/jquery/jquery-mobile/issues/3216#issuecomment-3607090

[cjblomqvist]

On my Galaxy S2 (GT-I9100), Android version 2.3.4, the true fixed header & footer in the demo @ http://jquerymobile.com/branches/css-fixed/docs/toolbars/bars-fixed.html is not working, but falling back to the old hide and transition. This got me curious as nobody else seem to have the same issue on Android 2.3.x so I also tested with the Android emulator using 2.3.3 & 2.3.1 (.2, .4 & .5 is not available, if I'm not mistaken) and it works perfectly fine.

Any ideas? Is it some setting or anything that I possible have turned on? I tried to refresh, drop the cache and reboot the phone, all without luck. Or is it a 2.3.4-specific or Galaxy S2 -specific verison?

Also, like previous people have reported, there are problems with the tap-to-toggle-visibility -feature (on all devices & versions)

[julianfuerderer]

Have the same problem... with Galaxy S2: See my post: http://forum.jquery.com/topic/orientation-or-scorrling-change-footerbar-links

[toddparker]

Hi all -

That branch is a bit outdated since this has been pulled into master. Can you re-test here: jquerymobile.com/test

[cjblomqvist]

Thx for letting us know Todd! Unfortunately I have bad news; It still doesn't work on my Galaxy S2. Let me know if there's anyway I could further help with debugging.