Skip to content
This repository

Fixed Headers/Footers Scroll with the document occassionally. #58

Closed
jblas opened this Issue · 69 comments

24 participants

Kin Blas Todd Parker Scott Jehl BMCouto M-Way Solutions GmbH fcgrx Stephen xboxbotox Jared Macke Jason Haag Dirceu Jr Raymond May Jr. Gabriel Grant Jeff Lembeck Mat Ellis Frank Panko Taylor luk skris Mathias Lin teehill ora726 bridgestew Garris
Kin Blas

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.

Todd Parker

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.

Kin Blas

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?

Kin Blas

I checked in the fix for this:

0a2a821

Todd Parker

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

Scott Jehl

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.

Todd Parker

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.

Scott Jehl

re API: how about:

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

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

Kin Blas

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"?

Scott Jehl

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.

Scott Jehl

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.

Kin Blas

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

9dce1c3

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.

Kin Blas

@BMCouto

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

BMCouto

At least on iPhone 3G and 3GS

Kin Blas

@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

M-Way Solutions GmbH

Any update on this one?

Kin Blas

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

Kin Blas

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

Stephen

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.

Todd Parker

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

Kin Blas

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.

1dad50e

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.

Kin Blas

I filed the 2 issues above as 860 and 861.

Scott Jehl

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

Todd Parker

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

Jared Macke

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?

Jason Haag

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

Raymond May Jr.

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.

Deleted user

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

Todd Parker

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

Jason Haag

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

Raymond May Jr.

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

Scott Jehl

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.

Deleted user

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

Todd Parker

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

Gabriel Grant

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

Jeff Lembeck

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

Mat Ellis

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

Frank Panko

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.

Taylor luk

Disable touchmove event, this fixes header/footer moves along with page scroll when your finger scroll from header or footer.

$('[data-role=footer], [data-role=header]').live("touchmove", function(e) {
  e.stopPropagation();
  e.preventDefault();
})
Deleted user
ghost commented

@speedmax I tried this workaround on my Incredible Android - I don't see any improvement

Scott Jehl

This issue should be fixed as of yesterday's commits. Please test alpha 4 and let us know if you see any issues! Thanks

Deleted user
ghost commented

This appears to be resolved on my Incredible Droid as of Alpha 4

skris
skris commented

This issue still very much exists on Alpha 4.1 and is very much a problem even when you don't touch the header and footer. Especially on iOS 4.3. It is more pronounced with Phonegap, but even outside of Phonegap, scrolling will produce odd positioning of the header and footer. Opening and closing virtual keyboard also seems to completely throw off the header and footer positioning. I'll create a screencast soon to show you what I mean.

Todd Parker

@skris - are you testing on the latest?
jquerymobile.com/test

It's far from foolproof because of the mechanics of how browsers render during scroll, but it's gotten a lot better. We're also planning on adding true position:fixed for browsers that support it (iOS 5, Android 2.2, BB playbook, etc.).

skris
skris commented

I'm not on the latest as I haven't had a chance to adapt changes in mobile.changePage(). I'm on the jquery.mobile-nightly-20110513.min.js. I know I shouldn't be testing against this, but I figured that since this bug has been closed since March, this nightly should definitely contain the fix. In testing more, it appears that static lists work just fine with the header/footer. Dynamically created lists pose a problem. When moving back and forth between pages while refreshing the list on "pagebeforeshow" makes the footer jump up and down before finally settling. I'll try this with the latest to see if this still exists. I'll also try to create a minimalist example to reproduce the effect. Maybe I'm doing something wrong with listview.

Mathias Lin

@skris I can confirm, I also have problems with the footer when I use it on the same page where I use collapsibles (http://jquerymobile.com/test/docs/content/content-collapsible.html), which are larger than the screen height. When I expand a previously closed collapsible (by touching it), and it's content is larger than the screen height, the footer is gone and doesn't get invisible - until I touch the screen again somewhere; only at that point the footer gets readjusted. (1.0RC1 code)
Here's a screenshot: http://imageshack.us/photo/my-images/38/footerbug.png/

teehill

@mathiaslin same scenario, collapsible content / any dynamic resizing isn't working as expected: footer gets pushed down from large content, pulls up too short for shorter content.

ora726

I have also noticed a problem with the keyboard display and the footer on Android.

Correct behavior on Iphone IOS5 3GS :
When the keyboard slide up to allow a data entry it slide over the complete page including the footer hiding it from view.

Incorrect behavior on Android 2.2 emulator (Sorry I lost my Android phone ...).
When the keyboard slide up the footer slide up to remain visible at all time and remain at the edge of the keyboard. Problem is that on a small screen the footer take most of the remaining real estate and limit the fields view. Once the input is finished the keyboard slide back with the footer, the footer however stop before reaching the bottom of the page.

Anybody noticed this and found a workaround ?

Thanks

I'm on 1.0 final and still get this issue sometimes when flick scrolling down especially (the fixed navbar footer will scroll with the page, then reposition itself correctly after a small delay).

EDIT: using IOS 4.1 on an iphone 4

Todd Parker

The issue is that when you start scrolling, the browsers tend to freeze the DOM so if you scroll fast, the toolbars can get stuck scrolling with the page. It's just a limitation of the approach.

We have an in-progress feature to use position:fixed which will give true fixed toolbars in many browsers. Check out the "css=fixed" branch.

ora726

Hi Todd,
I understand the problem when scrolling, but I don't understand why the toolbar shift up when the keyboard appear on an android phone, (See my previous post on the issue).
The behavior is only on android as the iphone keyboard appear above all page content.

Kin Blas

@ora726

I believe it's because only Android fires a document resize event when it shows the keyboard.

ora726

Hi jblas,
I did not know that, but then it's a perfect place to put code to hide the toolbar. Does it fire the event as well when hiding the kb ?

Kin Blas

@ora726

I believe it does.

bridgestew

Does anyone else experience the fixed footer flickering a few times on page load? After that flicker, it seems to be stable. Here's an example that does the flickering for me (jQuery Mobile 1.0) on my iPhone4 iOS version 5.0.1:

http://shallowthoughts.org/test/atlantic/

Garris

Androd 2.3.3 & 2.3.4: header data-position="fixed" works reliably.
Android 2.3.5 & 2.3.6: header data-position="fixed" does not work, it scrolls with document.

/bump

Jason Haag

This issue is closed. If you've found a new issue based on the latest version of jqm, open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.