Switch fixed toolbars to CSS position:fixed #3216

Closed
toddparker opened this Issue Dec 5, 2011 · 96 comments

Projects

None yet
@toddparker
Contributor

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
Contributor

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

@scottjehl
Contributor

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
Contributor

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
Contributor

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
Contributor

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
Contributor

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.

@scottjehl scottjehl was assigned Dec 12, 2011
@toddparker
Contributor

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
Contributor

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
Contributor

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

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
Contributor

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
Contributor

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
Contributor

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
Contributor

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
Contributor

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
Contributor

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
Contributor
negue commented Dec 19, 2011

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
Contributor

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
Contributor

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

@rbdcti
Contributor
rbdcti commented Dec 24, 2011

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
Contributor

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
Contributor

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
Contributor
rbdcti commented Dec 28, 2011

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
Contributor

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

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
Contributor

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

@staabm
Contributor
staabm commented Dec 30, 2011

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
Contributor

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

@scottjehl
Contributor

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
Contributor

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
Contributor

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
Contributor

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

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
Member
agcolom commented Jan 22, 2012

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

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:
#3216 (comment)

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

@toddparker
Contributor

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.

@toddparker
Contributor

@cjblomqvist _interesting. Our phone is running 2.3.6 but I wouldn't think that would matter. Is this a custom ROM or a standard install?

The only bug I see is the tap to hide only hides the header, not footer.

@cjblomqvist

Standard install. In my settings it says Base Version 2.6.35.7-I9100XWKI4-CL575468 (root@DELL143 #2). It's the version aimed for Europe, and specifically Sweden (might be the same). Quite weird!

The tap to hide -bug occur as well.

@dcarrith
Contributor

I just tested on a Samsung Captivate (Cricket) running Android 2.3.4 and here are some of the issues I see:

For reference, this is the page I'm testing:
http://code.jquery.com/mobile/latest/demos/docs/toolbars/bars-fixed.html

On initial load, everything looks great. The fixed headers and footers stay fixed in position.

There seem to be three scenarios of issues with the hiding/showing. If I'm all the way at the top, and I tap to hide the headers/footers, the footer hides as it should and the header stays in place, but...the header is actually still fixed (i.e. it does not fall inline as I think it should and neither does the footer...it's just gone). The opposite thing happens if I start at the bottom of the page and tap to hide (i.e. the header hides as it should, and the footer stays in place...but the footer is still fixed and does not fall inline and the header is gone). In both of those scenarios, the toolbar that does get hidden, does not fall inline (so, for example, if I then scroll all the way down or up to see where the header/footer landed, it is not there). The only way to get it back is to scroll back up to the top (if trying to re-show the footer) and tap to toggle (or scroll all the way back to the bottom if trying to re-show the header).

The third scenario is if I tap to toggle after I'm scrolled somewhere in the middle of the list. In that scenario, the header hides but the footer does not hide. At that point, it seems like the only way to hide the footer is to scroll all the way to the top and tap to toggle. Then, at that point, both will be hidden since the header will be gone as mentioned in the first paragraph. To get them both back, I had to scroll down a bit (so I wasn't all the way at the top anymore) and then tap to toggle (which showed the header) then I had to scroll to the top and tap to toggle again to then show the footer.

Sorry if that was confusing...I think I confused myself just typing it.

@agcolom
Member
agcolom commented Jan 25, 2012

Hi All,

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

I also get some very strange results (testing on FF8.0.1). So far, I have managed to:

  • get the footer to completely disappear (but not the header, which is still in fixed mode)
  • get the header to completely disappear (but not the footer, which is still in fixed mode)
  • get the footer displayed in the middle of the screen

but I have not yet managed to find what is causing this...

will try to find out more later today after work... (in about 10h), but I may be able to try again during a tutorial I have this morning in 3-5 hours.

I am not sure however that this is the correct file to test as there is still z-index:10; in .fade.in and z-index:0; in .fade.out which @scottjehl removed nearly 2 days ago... I tried to go to jquerymobile.com/test/docs/toolbars/bars-fixed.html which is where I would expect the latest version to be, but this redirects to http://code.jquery.com/mobile/latest/demos/docs/toolbars/bars-fixed.html

Anne

@scottjehl
Contributor

Hey all.

Thanks for the help and feedback. Unfortunately, I'm afraid that test URL is not updating properly. Some fixes that landed days ago negated several of these issues, such as the "the footer displayed in the middle of the screen " bug, so if you can pull down the code for now, that's the best way to test.

We'll try and get the urls fixed asap.

On Jan 25, 2012, at 3:22 PM, Anne-Gaelle Colom wrote:

Hi All,

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

I also get some very strange results (testing on FF8.0.1). So far, I have managed to:

  • get the footer to completely disappear (but not the header, which is still in fixed mode)
  • get the header to completely disappear (but not the footer, which is still in fixed mode)
  • get the footer displayed in the middle of the screen

but I have not yet managed to find what is causing this...

will try to find out more later today after work... (in about 10h), but I may be able to try again during a tutorial I have this morning in 3-5 hours.

I am not sure however that this is the correct file to test as there is still z-index:10; in .fade.in and z-index:0; in .fade.out which @scottjehl removed nearly 2 days ago... I tried to go to jquerymobile.com/test/docs/toolbars/bars-fixed.html which is where I would expect the latest version to be, but this redirects to http://code.jquery.com/mobile/latest/demos/docs/toolbars/bars-fixed.html

Anne


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

@scottjehl
Contributor

I wanted to add, just so it's clear what's expected here:

There are two modes, fixed and fullscreen. Fixed toolbars are always visible in the document, either "fixed" to the top of the screen, or static at the top or bottom of the document. So with fixed toolbars, tapping will not always hide them from view; it depends if you're at the top or bottom of the page. At the top, the header won't hide, it'll just fall back to static positioning, but still visible, while the footer will hide from view as it moves to the bottom of the document. If we didn't do this, you'd see gaps at the top and bottom when the bar is hidden... didn't seem to make much sense to us that way.

For "fullscreen", the bars sit on top of the content, and when they hide, they hide from the viewport entirely. They're actually chucked off the page, still accessible from a screen reader point of view, but gone for sighted users. Fullscreen bars are good for interfaces that don't involve a lot of scrolling, and are meant to feel more immersive, like a photo viewer, for instance.

Anne, I'm not sure if this distinction clears up any of the bugs you mentioned, but it seems like it might be related to some of the issues tagged in this thread.

I just tested a few desktop browsers on Master and the tap to hide behavior feels pretty good to me. Firefox latest, and Chrome.

Hopefully at least a few of these bugs amount to a bad test URL, but if not, please let us know what's breaking!

Thanks.

@dcarrith
Contributor

@scottjehl, thanks for clearing that up. I think I might have confused a description of the code changes (I think you announced somewhere) with expected behavior. I think one of the changes in the code was to put the header and footer markup in divs where they would naturally occur in the dom (i.e. where they would exist if the page just had normal un-fixed headers and footers) and then let the code reposition them when needed.

I guess it makes sense to chuck them off the page since the whole reason the user is tapping to hide them is to make more room in the viewport. For my application in particular, it leaves a noticeable gap at the top and bottom of the page. I'll likely turn off the ability to tap to hide them. If I was going to have that functionality enabled, I guess I would have to handle the gaps at the top and bottom better (like move everything up at least).

@dcarrith
Contributor

After pulling with: git clone git://github.com/jquery/jquery-mobile.git
I compiled and then moved the css and js files into place then cleared Chrome's browsing data from the beginning of time (Chrome v.16.0.912.75 m on Windows 7).

1.) While at the top of the page, if I tap to hide, the footer is chucked off the page, but the header remains in place where it naturally exists on the page, and it is no longer fixed.

So, either the header needs to also be chucked off the page (to be in "fullscreen" mode) or the footer should fall inline at the bottom of the page where it naturally occurs in the dom (like the header is doing). Or, maybe the header just had not gone into floating/fixed mode yet since I hadn't scrolled at all.

2.) While somewhere in the middle of the page, tapping to hide seems to work great. It chucks both header and footer off the page entirely (goes into fullscreen mode correctly). However, bringing them back only works as expected if I remain somewhere in the middle of the page. If I scroll all the way to the top and try to tap to show, only the footer shows. If I scroll all the way to the bottom and tap to show, only the header shows.

3.) This one is interesting. Scroll to the middle, then tap to hide, and they both hide. Scroll to the top, and tap to show, and only the footer shows. Scroll back to the middle, then tap to hide, then tap to show, and the footer shows but the header only shows for a second before it gets put back inline at the top of the page. The opposite scenario is also true.

I also just tested on an original iPad running iOS 5.0.0 and had the same experience.

Just tested on in stock browser on CM7.1.1 on a Thunderbolt (Android v2.3.7) and got slightly different results. Here are the differences:

1.) The footer is chucked off the page and the header remains in place, and it is still fixed.

2.) Same issues as above

3.) Could not recreate this one on my Thunderbolt.

Besides those couple of things, @scottjehl, you've made great progress overall! Thanks!

@agcolom
Member
agcolom commented Jan 25, 2012

Hi Scott,

Thanks a lot for the clarification. This is exactly as I would expect it to work, so I am happy to see that we have the same view here... I've noticed that the file we are seeing is still not the "proper" latest version with all your changes, so will try again later...

best wishes,

Anne

@julianfuerderer

Hello,

i have done many research via google to fix the problem.
I have a Samsung Galaxy S2 (Android 2.3.4), programming with Eclipse+jQueryMobile+Phonegap.

To describe the problem, i have also tried the Static-Footer-Bar example from
the official documentation:
Please visit

http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html

The flow:

1. Coming to http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html

2. After some clicking the links in the footer-bar the following happens:

I am on the page "Albums" and click on "Friends": Friends-Page not coming/loading and
Albums and Friends Links both stay in active-link state

Any Idea ?
Please help me...

@agcolom
Member
agcolom commented Jan 26, 2012

Hi Scott,

Looks like I am getting the correct file version now... can you let me know when you're ready for me to test (as I can see you are making changes now). I still see the issue with headers or footers not displayed when they should in some very specific cases. I can give you a full report this evening (in about 8h).

Anne

@cjblomqvist

@scottjehl: Update on Galaxy S2 -issue: I tried http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html today and the issue with the true-fixed-positioned header/footer is gone. Now they follow the scrolling in a true persistent manner. Awesome work (as always)!

@julianfuerderer: I have seen this issue on multiple occasions on different elements in jQueryMobile, including the navbar, header, as well as the listview, and from testing I have a feeling that this problem happens when you manage to click after the page has loaded itself but before the browser is receptive to new (link-) clicks. Another guess would be that it happens when you do a touch that is too short - if I'm not incorrect the framework uses timers to decide whether to count it as a click or not? Regardless of the issue, I'd recommend using the stable 1.0 version instead of the latest development version until things have been properly sorted out.

@dcarrith
Contributor

@scottjehl: I just pulled down the latest and am seeing some great improvements. It seems like you've addressed everything that was reported yesterday. I have noticed a few issues that are a bit more esoteric and may just be caused by the way in which I've implemented something in my application. I haven't been able to reproduce them consistently though, so I'll report back on those later if I can identify something that might be related to the changes made for 3216.

There is one thing I've noticed that is probably related to the changes made for 3216. In my header, I have a back button and a home button. If I'm scrolled down in a page of Artists, for example, and I tap either of the buttons in the fixed header toolbar, it seems to usually register the tap event on the element below the fixed header toolbar. So, instead of going back, it selects whatever artist li element is under the toolbar. It doesn't seem to happen in Chrome on Windows 7, since I guess that isn't a tap event. It happens frequently on iOS5 and Android 2.3.7 stock browsers. If I very carefully do a kind of long tap (but not long enough to be a taphold) on the back button, I can most of the time get it to go back. But, it wasn't like that before these changes were made.

@scottjehl
Contributor

Hey Anne, and everyone else,

Please go forth and test away - I've got one item I'd still like to nail down on these (a list of tap targets that should be ignored for toggling toolbars, like anchors, form controls, etc).

Aside from that, the docs are updated now with all the new options and API details, as well as expected behavior.

Thanks again, you guys are all a huge help!

On Jan 26, 2012, at 6:57 PM, cjblomqvist wrote:

@scottjehl: Update on Galaxy S2 -issue: I tried http://jquerymobile.com/test/docs/toolbars/footer-persist-c.html today and the issue with the true-fixed-positioned header/footer is gone. Now they follow the scrolling in a true persistent manner. Awesome work (as always)!

@julianfuerderer: I have seen this issue on multiple occasions on different elements in jQueryMobile, including the navbar, header, as well as the listview, and from testing I have a feeling that this problem happens when you manage to click after the page has loaded itself but before the browser is receptive to new (link-) clicks. Another guess would be that it happens when you do a touch that is too short - if I'm not incorrect the framework uses timers to decide whether to count it as a click or not? Regardless of the issue, I'd recommend using the stable 1.0 version instead of the latest development version until things have been properly sorted out.


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

@agcolom
Member
agcolom commented Jan 26, 2012

Todd, your link redirects to http://code.jquery.com/mobile/latest/demos/docs/toolbars/bars-fixed.html and the jquery.mobile.css does not seem to be the latest one (z-index is there for .fade.in and fade.out), but this morning (about 7h ago) this was different (z-indexes were not there).

It seems this is reading http://code.jquery.com/mobile/latest/demos/css/themes/default/jquery.mobile.css which does not seem updated??

@toddparker
Contributor

Yeah, we're having lots of issues with the redirects. /test/ was working for me but if you get redirected, that other URL is out of date. Working on it.

@agcolom
Member
agcolom commented Jan 26, 2012

Todd, Scott,

the redirect issue seems to be related to which computer I use! All works fine with my new MacBook Air running Lion with FF9 and Safari 5.1.1 (and the transitions on the fixed headers and footers are absolutely gorgeous!!!!)

With my MacBook Pro running Snow Leopard, I get the redirect with FF8 and now it's all fine with Safari 5.1.1 there as well... I wonder whether this could be a cache issue on FF8. I'll try to clear the cache...

@agcolom
Member
agcolom commented Jan 26, 2012

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
Member
agcolom commented Jan 26, 2012

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
brunnsbe commented Feb 2, 2012

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
Contributor

@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
brunnsbe commented Feb 3, 2012

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
Contributor

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
Contributor

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
Contributor

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 scottjehl pushed a commit that referenced this issue Feb 6, 2012
scottjehl Addresses issues with #3216, where fixed toolbars could not be toggle…
…d on Android, or if toggle-able, they would scroll with the page at load, only working after toggling their appearance manually. With this change in place, scaling properly disables on Android 2.3 when fixed toolbars are in play (an apparent requirement for fixed positioning to work on that platform), while ensuring zoom can be restored after visiting a page that does not have fixed toolbars, at least on iOS.
83c09a9
@scottjehl
Contributor

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
Contributor

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
Contributor

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
Contributor

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
ricky-f commented Feb 8, 2012

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
Contributor

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

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

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.

@toddparker toddparker closed this Feb 22, 2012
@scottjehl
Contributor

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
Member

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

@tbosch tbosch referenced this issue in angular-widgets/angular-jqm Jul 1, 2013
Closed

feat(widget): fixed toolbars #11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment