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:
#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:
#3216

---

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

---

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

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

[agcolom]

OMG!!! I have cleared the cache and do not get the incorrect redirect anymore!!!
So if anyone else reports incorrect redirect, the solution could simply be to clear the cache!!! Sorry for causing you so much extra work!!!

[agcolom]

Hi Scott,

Tiny minor things when testing http://jquerymobile.com/test/docs/toolbars/bars-fixed.html

in FF8.0.1 and FF9, when at the bottom of the page there is something like a 1px difference between the fixed footer and the normal footer (play with position: abolute (remove it and bring it back) in your element inspector, you'll notice the difference)...

.ui-fixed-hidden {
    position: absolute;
 }

But I think this is a problem with the browser itself, as there are other cases of JQM elements with the same minor pb...

In Safari 5.1.1, if you toggle while at the top of the page or at the bottom, no problem at all. However, if you toggle while in the middle of the page (anywhere really but so that you cannot see the non-fixed header and footer) and toggle to display the bars, the text in the header and footer looks a bit bolder. if you then move to the bottom of the page and toggle again, you'll see the difference in the display of the text in the footer: bolder when fixed positioning is shown, and not bold when normal footer is shown. If you do the same with the header, i.e. go to the middle of the page and toggle to display fixed bars. now go to the top of the page, and toggle again. The header remains bold. Now, go again to the middle of the page, toggle to show fixed bars, look carefully at the bold looking header, toggle to make it disappear from the current view and scroll to the top. Look at the header text, it is not bold anymore. If you toggle from here the header and footer will be displayed without the bold look...

I have not managed to put my finger on what is causing this... really quite minor... and the transitions look amazing!!!

Anne

[brunnsbe]

I made some new testing using http://jquerymobile.com/test/docs/toolbars/bars-fixed.html on Nokia N9 (Meego 1.2, built-in browser, release PR 1.1) and it still doesn't work.

• The fixed footer isn't fixed at the bottom, its position is fixed and doesn't scroll with the rest of the document.
• The fixed header is only shown at the top of the document
• Clicking on the document toggles the visibility of the footer but in quite an ugly way, it blinks a few times.

[toddparker]

@brunnsbe - Thanks, I just re-tested on my N9 and the browser has a broken :fixed implementation so we need to forcefully degrade this to static positioning by blacklisting it. It amazes me how many mobile browsers shipped with a completely broken fixed feature.

[brunnsbe]

Yes, it's quite annoying with the broken implementations. :-(
The N9 will get a new firmware in the end of this month (PR 1.2), I read somewhere that the new firmware also contains upgrades to the internal browser. Hopefully the broken :fixed implementation has been fixed in that release.

Edit (28.2.2012): I have now tested the PR 1.2 release and the :fixed implementation is still broken.

[scottjehl]

Just an update: n9 should be opted out now, and the toolbars should toggle properly in Android.

On Feb 3, 2012, at 5:28 PM, brunnsbe wrote:

Yes, it's quite annoying with the broken implementations. :-(
The N9 will get a new firmware in the end of this month (PR 1.2), I read somewhere that the new firmware also contains upgrades to the internal browser. Hopefully the broken :fixed implementation has been fixed in that release.

---

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

[toddparker]

Our N9 is now falling back to static positioning on toolbars in master.

[JasonBSteele]

When I test http://jquerymobile.com/branches/css-fixed/docs/toolbars/bars-fixed.html on a Galaxy Nexus with Android 4.0.2 I get the following behaviour:
The toolbars are solidly fixed and scrolling is smooth
However if I tap the screen the toolbars disappear and then very quickly reappear.
Also if the inset list on this page happens to be under a toolbar, when the toolbar reappears it is behind the list.

IMHO I tend to agree with a previous comment on whether the touch toggle should be the default behaviour or included at all if it causes problems.

[scottjehl]

Hi @JasonBSteele - just a note, that's an old url. If you can, test on latest master, as that's where we've been working on this feature for the last few weeks.

[scottjehl]

Okay, folks, I think we're probably in as good of shape as we're going to get with this one. Support is looking great on a boatload of devices, and falls back respectably in most others we've tested.

My latest commit allows for toggling in Android while ensuring fixed toolbars still stay fixed at pageload, on most Android 2.3 devices, such as the emulator, and I'm assuming many other popular devices.

@toddparker with your testing confirmation, I'd like to declare this one ready. Here's some additional detail of what I found today:

There are some edge cases to fixed support, even within OSs that are supposed to work: I've found at least 2 stock Android 2.3 devices (HTC devices with Sense UI, and Samsung Galaxy Mini) have webkit ports that do not allow user scaling to be disabled at all through any apparent means. While this is generally a good thing for users, it means position: fixed doesn't work in those places either, since zoom must be disabled on 2.3 for that to work. In these platforms, you'll get scrollbars that scroll with the page content and reposition after scroll. Opting them out of fixed will mean slicing our UA detection even further to target specific carrier implementations of 2.3... the need for a solid feature test is getting even more important!

I found that you can actually get position:fixed to work on 2.3 without disabling user scaling if you apply a 3D transform to the fixed elements. However, that transform prevents the elements from being toggled to other positioning models, like absolute, which is a feature we need for supporting our toggling. Not helpful for us, but maybe for others. Here's a sample page with zoom enabled that works on 2.3: http://jsbin.com/izakek

In the commit above, I noticed that zoom wasn't properly being disabled on common Android 2.3 devices with our $.mobile.zoom utility, and adding user-scalable=no to our existing maximum-scale=1 disabling value seemed to fix that without disabling zoom for good on iOS...

Anyway, it's clear that there are some implementations out there that this may cause some issues in. We'll have to watch it closely, and if anyone has ideas for a new approach to feature testing fixed (that doesn't introduce false results on some platforms), we are so interested :)

[scottjehl]

Oh, lastly, please test Master or the following URL, which should be up-to-date now:

http://jquerymobile.com/test/docs/toolbars/bars-fixed.html

[toddparker]

Works great on both our Android 2.3 devices and our 2.2 phone. I think that if an OEM has monkeyed with the browser settings, there isn't too much we can do really. Not hiding the fixed toolbars when the keyboard opens would be usability disaster, especially on short screens or landscape mode so if we need to pick our poison here, I'd go with the more standard approach that preserves the toggle behavior. We should document this tradeoff int eh docs how to turn of the toggle behavior and where to apply that transform so if someone is building a native app and they are careful, they can go the other way.

One small thing we might want to consider adding: If you're focused in an input (toolbars are hidden) and immediately tap on another input, the toolbars briefly show then hide. Wonder if we can keep them hidden if you blur but focus back within a brief time window.

[toddparker]

The last thing we need to do is make some test pages with more form elements inside fixed toolbars to see how everything works. @Wilto is working on finishing up the elements so we can do that soon. We should have a bunch of demo pages showing how these work.

Oh, and here's another critical reason for not adding the transform: People were reporting that the home button wasn't clickable if you scrolled down a bit with the transform in place. Just another Android bug, but a huge usability issue.

[ricky-f]

Hi Guys,

Great job on this so far. I’ve been testing on iOS 5.0.1 and have discovered an issue. When using fixed toolbars with clickable form elements in them. After you call $.mobile.silentScroll(), the toolbar visually remains in place but the form elements are no longer clickable. It appears that the ‘click’ area does not reposition properly. Performing a manual scroll seems to set this right again.

I’ve put together a little demo here http://www.philliphaydon.com/scrolldemo/ Source is here https://gist.github.com/1763662 to demonstrate the issue. This appears to only be an issue on iOS 5.0.1 so you will need to run it on an iOS5 device to reproduce the issue. Click on the ‘PAGE DOWN’ button in the footer toolbar once, the page will scroll. Then try click on it again and you won’t be able to. If you then manually scroll it resets and you will be able to click the button again and reproduce the issue again. This also happens for form elements in the header. E..g in the example, click page down and then try click the home button which won’t do anything.

If you want to visually see where the clickable area is repositioning to, you can turn tapToggle to true then click the ‘PAGE DOWN’ button, the page will scroll, click it again and then the toolbars will hide and then click a third time where the ‘hidden’ button should be and the toolbar will appear towards the top of the page. This is where the clickable area has gone. Let me know if you have any questions.

Thanks,
Ricky

[hallatore]

http://jquerymobile.com/test/docs/toolbars/bars-fixed.html
This one doesn't do anything on wp7. header and footer are both static.

[toddparker]

@hallatore That's right. The new fixed toolbars in 1.1 rely on a browser supporting position:fixed. If this isn't supported, the toolbars will simply scroll with the document. The older technique where we dynamically re-position the bars after scroll won't be supported in 1.1 because this technique adds a fair amount of code weight and isn't super reliable (bars scroll with the page, etc.).

[ssssssssssss]

Just filed a bug about the position:fixed implementation in ICS 4.0.2 stock browser.
http://code.google.com/p/android/issues/detail?id=25610
Does anyone hit the same issue? Currently, I doesn't find a way to workaround.

[cjblomqvist]

sssssssssss: Yepp, I hit the same issue (also ICS 4.0.2 stock browser).

[barbalex]

Es, Same here
Am 16.02.2012 14:20 schrieb "cjblomqvist" <
reply@reply.github.com

:

sssssssssss: Yepp, I hit the same issue (also ICS 4.0.2 stock browser).

---

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

[barbalex]

Es was to mean yes
Am 16.02.2012 17:21 schrieb "Alexander Gabriel" <
alexander.gabriel@bluewin.ch>:

Es, Same here
Am 16.02.2012 14:20 schrieb "cjblomqvist" <
reply@reply.github.com

:

sssssssssss: Yepp, I hit the same issue (also ICS 4.0.2 stock browser).

---

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

[phillip-haydon]

Is anyone able to answer this question?

#3216 (comment)

[scottjehl]

@phillip-haydon and @ricky-f :

ugh, sorry. I spent a long time responding to this one and now I don't see my message in the thread. The form must have never submitted.

I did a bunch of testing on this and found that this bug is indeed present in iOS5, and it has nothing to do with jQuery or jQuery Mobile. Here's a framework-free example that reproduces the bug.

http://jsbin.com/iredok

source:
http://jsbin.com/iredok/edit

For anyone programmatically scrolling a page that has form elements in a fixed footer, this bug is going to be a major problem. It doesn't appear to affect default use cases of jQM, even though we do programmatically scroll to remembered locations when returning to a page. I think it's because we do it before the page is is visible. Not sure though.

I don't think this should be a blocker for our feature, but we should probably make a note of it somewhere in the docs.

I wasn't able to find any workarounds. Let us know if you do.

I'll file a bug with Apple - maybe it'll be fixed in a future release :(

[toddparker]

Hi all - I'm going to close this issue as fixed now that the new fixed toolbars have landed in master. Please help us test these this week so we can shake out any issues. Log as new issues please.

[scottjehl]

Woo! Thank you all for all the testing and feedback during development.

On Feb 22, 2012, at 10:05 AM, Todd Parker wrote:

Hi all - I'm going to close this issue as fixed now that the new fixed toolbars have landed in master. Please help us test these this week so we can shake out any issues. Log as new issues please.

---

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

[abhipanda]

Thanks a lot for this stupendous effort.

[rauanmayemir]

I have issue with fixed toolbars on small screens (320x480).
To reproduce, try to open initial link in android emulator for stated resolution: http://jquerymobile.com/demos/1.1.0-rc.2/docs/toolbars/bars-fixed.html

[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 get a workaround for but haven't succeeded yet, so any help would be grateful! The testing was done on ios 5 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 and show the address bar, navigate to another page that is not full (as in occupy only half of the page with listview or something). The footer will rise from the bottom. It can be set back by scrolling. I tried to trigger a scroll event every time I switch pages but that doesn't seem to fix the issue. Please help!

[jaspermdegroot]

@rauanmaemirov @balshamali This issue is closed 2 months ago with a comment to open a new issue to report problems with fixed toolbars.