Fixed Headers/Footers Scroll with the document occassionally.

[jblas]

I'm not totally sure what the intended behavior is of fixed headers/footers, but I'm basing this on the behavior I see when running the Fixed Toolbars sample on the Desktop browsers.

When I first load the sample on an iPod Touch (iOS 4.1), the header and footer are where they should be. If I attempt to flick scroll the document so I can see things further down the page, the header and footer scroll with the document. They don't correctly position themselves at the top/bottom of the view port. I have to tap on the document before they will re-position themselves.

[toddparker]

They should both appear on load and slide back into view on when scrolling stops. If you tap the screen, they will hide until you tap again, then they will slide in on every scroll stop again. This lets you choose whether they keep re-appearing. They are buggy now so you'll see them break in a lot of cases...feel free to patch these up.

[jblas]

I took a quick look at this and it appears that this bug is triggered because a scrollstart event is fired off while in the midst of handling a scrollstop. This ends up throwing off the setting of showAfterScroll, so the currentstate gets stuck at "inline" so nothing moves from that point on.

If we move the setting of the showAfterScroll value so that it comes before the show/hide calls, it fixes things.

Also, should the hide() call in the scrollstart handler be done within the 'if' check?

[jblas]

I checked in the fix for this:

https://github.com/jquery/jquery-mobile/commit/0a2a82102ea8f418131cc28b39456dfd3393d223

[toddparker]

This fix made the toolbars and global much better. It's not nearly as breakable now. Nice work!

[scottjehl]

This issue is particularly bad now. I'm not sure if a recent change caused a regression, but it seems scrollStart and scrollStop are not firing reliably to show and hide the toolbars on time.

[toddparker]

I'd like to recommend that we have fixed headers/footers set as a global config option and default to it being off. You should be able to enable it by adding a data-position=inline|fade|slide attribute (name TBD) to allow us to add multiple ways to animating and displaying this. Eventually, "fixed" may be an option if we get simulated scrolling working.

[scottjehl]

re API: how about:

<div data-role="footer" data-type="inline|follow|fixed" data-transition="fade|slide" data-id="uniquefooterid">

[scottjehl]

ugh.. trying again: <div data-role="header|footer" data-position="inline|follow|fixed" data-transition="fade|slide|none" data-id="uniqueIDforPersistingAcrossPages">

[jblas]

Just so I'm on the same page ...

• "inline" means static positioning in the flow so headers/footers scroll with the document.
• "follow" is the behavior we see today where headers/footers disappear while scrolling and animate/reappear when it stops.
• "fixed" uses view port fixed positioning? If we were using simulated scrolling, wouldn't we be using a fixed size div (clip view) that fits between the header and footer? Wouldn't that mean the header/footer are still "inline"?
• Does data-transition only apply when data-position="follow"?

[scottjehl]

Good points.

• "inline" is the default. Not to be confused with block vs. inline. Maybe another term would be better (default?), but really, it's the option that'll apply if you don't specify a data-position, so we may not need it.
• yep - "follow" means you'd like them to be buggy and annoying in most cases :)
• Yeah, I guess fixed and inline are kinda the same. I was just leaving the possibility open that you could "fix" just a header, and we'd somehow handle the HTML wrapping to make the content and footer scroll together. In the end, we might leave that up to the developer anyway though.
• yes.

[scottjehl]

By the way, the "scroll with the document" issue seems to be due to DOM manipulation being frozen during scroll on iOS. Even though we're actually applying the manipulation on "touchstart", it doesn't always seem to happen fast enough. Sometimes though, it works just fine.

[jblas]

Checked in a workaround for the "scroll with the document" problem:

https://github.com/jquery/jquery-mobile/commit/9dce1c3c02836ea4064ad82945d2901a00f191e8

I'm going to try and spend some time over the next couple of days trying to fix positioning problems.

[BMCouto]

any news on this one? it happens almost all the time.

[jblas]

@BMCouto

What OS, version, and device are you seeing this problem on?

[BMCouto]

At least on iPhone 3G and 3GS

[jblas]

@BMCouto

I forgot to ask what page you are seeing this on too so we are looking at the same thing. Do you have an URL?

[BMCouto]

Yes, please check here - http://goo.gl/H7FVr

[mwaylabs]

Any update on this one?

[jblas]

@mwaylabs

I got side tracked for a bit and just got back to looking at this again.

@BMCouto

Thanks for the URL. Just to be clear, the problem you are referring to is how on iPhone/iPodTouch, when the page is loaded, the footer is positioned at the bottom of the viewport, but when the navigation bar scrolls off the screen, causing the viewport to grow, the footer is no longer anchored to the bottom of the viewport?

If so, I had a fix in mind that I'm still tweaking, because the different flavors of webkit on the various platforms all dispatch, or fail to dispatch, the same events.

[BMCouto]

Thanks jblas, we'll be waiting for this fix. Really important for me!

[jblas]

@BMCouto

Is the problem I mentioned above, the one that you are concerned with? I just want to make sure I'm fixing what you need and not some other problem.

[BMCouto]

@jblas yes it is. Sorry I missed that answer. In fact, sometimes the footer isn't even on the right position when the page is loaded, but definitely the problem is when you start scrolling.

[fcgrx]

Also waiting for this fix. Without truly fixed header and footer (with scrolling content in middle) we cannot use jQuery Mobile. For us, that and general performance speed on iPad/iPhone are critical.

[salonmonster]

Bump for this issue. It's a must have for us too.

[BMCouto]

I think this issue should be considered as Critical, since it's a major functionality that can't be used at all.

[toddparker]

Hey all, I just bumped this up to critical. Kin has been working on this so hopefully, he'll have a breakthrough soon.

[BMCouto]

Great! We'll be waiting :)

[jblas]

I just landed a fix which makes the headers/footers position themselves correctly after a silentScroll(). This should take care of BMCouto's problem. The fix should also improve positioning for Android browsers too.

https://github.com/jquery/jquery-mobile/commit/1dad50e53600df4bbc07ff6da7396600223c5c56

This bug has morphed a bit in meaning so I think I'm going to open separate bugs for some of the remaining issues I noticed:

• On some Android browsers, the header/footer scroll with the document, but reposition themselves correctly after the scroll is finished. This is likely due to the fact that the browser is scrolling a snapshot of the layout viewport, that was taken prior to the header/footer hide() call.
• The fix I just checked in causes headers/footers to reposition themselves properly after a resize or silentscroll. Unfortunately, on some Android browsers, the display of the virtual keyboard that displays after clicking in a textfield/textarea, causes a resize event ... this means that a fixed footer will reposition itself within that minimized viewport whenever the keyboard shows up.

[BMCouto]

Thanks a lot jblas, will try out your fix, and hopefully it's ok on the iphone.

[jblas]

I filed the 2 issues above as 860 and 861.

[scottjehl]

big Kin Blas fan here... big one :)

[toddparker]

Hi Kin - I just tested this on my iPhone 4, Droid (2.2) and BB6 and it's solid on all of them, there are some scrolling artifacts like you said but it always fixes itself in the end which is impressive. Awesome work. Can't wait to finally use this feature now that it's working better.

I'm sure we can keep refining this to improve performance and minimize scrolling artifacts but I think this is working as well as it generally can within the abilities of these devices. Should we close this issue?

[xboxbotox]

Hi all,

Excellent discussion - I think I'm having an issue similar to BMCouto's. When viewing on an iPhone, my persistent footer doesn't snap to the bottom because of the scroll that happens to hide the address bar in Safari. I attempted to use the fix that jblas describes, but it doesn't seem to help.

I wonder if perhaps I'm implemented the 2 new js files incorrectly? I see the fixHeaderFooter file is a plugin, but what about jquery.mobile.core.js? Should that too be included as a plugin, or should I manually update another file with the outlined changes?

Here's a link:

http://myclark.net/jquery/navTestFooter.html

[kcrbba]

I believe my issue is the same as xboxbotox. Can anyone explain (or point me to an explanation) of how to apply such a fix?

[jhaag75]

I have tested this using the fixHeaderFooter file as a local js file and it appears to resolve the issue with the header and footer snapping into place when fixed positioning is set. However, I am seeing an issue now where if you tap the screen they don't reappear. This fix works fine on Web OS 1.4.5, but I'm seeing some buggy behavior still on iPhone 3.1.3 and Android 2.2.2.

[dirceu-jr]

In Milestone I'm seeing fixed header working mostly nice but on Nexus One the header is always raising when I back from another page :S

[octatone]

Not sure if this is the same issue, but on iOS 4.2 with alpha 3, my fixed header over a nested list likes to occasinally (I'll say frequequently) jump around (from the top to somewhere below middle) before sliding to the child list.

[ghost]

I'm sorry to have to say this, but I think the entire approach regarding the header, footer and page transitions is wrong. To resemble a native app as much as possible, the header & footer should have fixed positions and only the content should change. As long as a page transition includes the header & footer, there will be a flipping effect and some jumping around. I wouldn't complain if this wasn't such an important component for a web app, it can ruin the entire user experience if it's not done right.

[dirceu-jr]

Have to say I agree with alexandraanghel. Scrollview seem to be the right way but it was laggy. iScroll is more smooth :)

[toddparker]

@alexandraanghel @dirs I think we'd all like to have perfectly fixed headers and smooth transitions and we're doing a lot of work to refine these as we head to 1.0. However, pure JS scrolling like iScroll can make form elements completely unable on many non-iOS platforms which frankly isn't an acceptable tradeoff. We're building our own Momentum scroller that should work on more platforms and ve targeted so as to not break the experience on non-capable platforms. Lastly, we're focusing primarily on tools to build widely accessible and elegant web apps, not installed apps

[fcgrx]

+1 for alexandraamghel's comment

I understand this may be problematic, but without simple fixed header and footer with scrolling content in middle, jquery mobile is hard to take seriously. this is a must have for us.

[jhaag75]

Have any of you upgraded to the new alpha release? I haven't had any problems since the new release. The fixed header and footers work nicely now.

http://jquerymobile.com/2011/02/jquery-mobile-alpha-3-released/

Make sure you update to alpha 3 (if you haven't already).

[octatone]

@jhaag75

There are still problems with fixed headers in alpha 3 including "fixed" headers jumping, disappearing, and rendering in the wrong place when navigating between pages.

Just take a stroll through the issue tracker and you'll find people submitting new tickets over fixed headers.

[scottjehl]

Hi fogcity, To be fair, "simple" is a bit of an understatement in regards to the complexity of implementing this feature in a way that follows-through on this framework's goals & philosophy of cross-device accessibility. There are many scripts and frameworks out there that provide a fake-scroller feature, but none of them (that I know of) are held to the same accessibility requirements of jQuery Mobile (which is simply that the content should be usable in some way in all browsers and devices). To most of our audience, shiny features don't mean much if they compromise this baseline requirement.

We have a scroller plugin in the experiments directory that's coming along well. You're welcome to use it if you're okay with your site's content being potentially inaccessible on some devices. If your project is targeted at a narrower audience than we strive to support (like an app store perhaps), there are some great scripts available for you to consider.

Also, if you've got a workable solution for this, we welcome dev contributions.

[ghost]

@scottjehl I don't exactly agree with you because I believe that a lot of people are using jQM exactly because it promises the shiny features. Otherwise, what is the point of using a javascript framework in the first place? And I have seen that most comments and complaints are about the interface (and various bugs), not the cross-device accessibility.

Don't get me wrong, I do favor jQM and appreciate the work that was done so far especially because it's not simple. The way I see it, jQM can turn into something really great and , why not, into an alternative to native apps simply because it's easy to use, open source and jQuery has a large community. But, in order for that to happen, the interface has to be pushed up the priorities list.

[toddparker]

Issue #860 is a duplicate of this issue but there is some conversation there I want linked up to this.

[gabrielgrant]

@toddparker as mentioned here @jblas opened #860 and #861 to track the specific variants of this issue identified in this earlier comment.

[jefflembeck]

It certainly works significantly better than it used to (thank you!), but I can recreate this if I am touching the header or footer while scrolling (testing on iOS4).

[matellis]

See issue #1197 for something that may be a dupe of this bug but is still affecting us.

[fpanko]

I'm seeing this issue in android 3.0 on xoom tablet. Additionally, when you scroll down past where the address bar is in the browser, the footer repositions itself approximately 2-3ems above the bottom of the page. This appears to be the same height as the browser's address bar.