Buttons not working with fixed header/footers when programatic scroll is used

[gabaum10]

Tested in HTC Incredible 2 (Android 2.3.4).

When you have a fixed header/footer, if you scroll down so are not at the top or bottom, any buttons will not fire. This includes anything that will display a menu or fire an action. The back button does not work either.

[Wilto]

There are a number of Android bugs related to fixed positioning—but unrelated to jQuery Mobile—that cause issues along these lines—some of which are detailed here ). We’re currently discussing ways we could potentially mitigate these problems.

I’m unable to reproduce this in the docs, but I’m confident it’s a real problem knowing what I do now about Android’s broken implementation of position: fixed. It would be a huge help if you could to put together a minimal test case using the template at http://jsbin.com/omacox/edit, reproducing the issue. It’s one part of a larger conversation for sure, but the more information we have at our disposal the better.

Thanks!

[gabaum10]

Yeah, I was unable to reproduce it in the docs either. Let me see if I can whip up an example.

[gabaum10]

Great, I can't replicate it with a simple example now. If I add custom styles to the header/footer, would that tweak out the behavior?

Check this out, it looks ok: http://jsbin.com/ezakib/3/edit

Now, what's weird is, in my app, after things are loaded dynamically, sometimes the footer appears in the middle of the list, and never repositions itself.

[gabaum10]

Oh! I may have found something, if you trigger a silent scroll, it tweaks everything out, which actually makes sense lol. Dynamic content, along with a silent scroll could be the issue.

Thinking about it, that's why the buttons weren't being triggered. I think it's because the DOM thought the buttons/header were still positioned at the top, because it was scrolling without firing a notification.

[gabaum10]

man, after reading your comments in the other post, that sounds like exactly what I am dealing with. That's brutal. Looks like we can't really take advantage of fixed positioning until either the browser makers fix it, or we can come up with some workaround. :(

[scottjehl]

This issue has been opened and closed a few times in the past month or so, and I frustratingly can't find any of them!

But I did find the simple demo I made to reproduce the issue without jQM at all. The buttons in the footer can be clicked once to scroll the page, then they'll be unclickable. The focus/target area of the buttons actually leave the button boundaries!

http://jsbin.com/iredok

The only way to restore it that I could find is to interact with the page - toggling page display didn't seem to help, and neither does toggling style to trigger a reflow, like tweaking the padding on the page to something large, then removing it again.

The problem is not just in Android - it's iOS5 too! It's only an issue with programmatically scrolling the page - user scrolling doesn't cause any problems that I can see. It only seems to affect real form controls, like input, button, select, etc - anchor buttons seem to be fine.

One last oddity: double-tapping the buttons works in iOS5. I'm not sure why.

Given that this is not our bug, I think the best we can do is document it so people know not to do it: "If you're using form controls inside fixed headers, do not programmatically scroll the window."

We should also avoid in-page scrolling in our own components: for example, we were considering scrolling the page programatically when collapsibles are expanded, but that'll potentially introduce this bug.

@Wilto @toddparker - agree on documenting and closing?

[toddparker]

If we can't figure out a way to bring these elements back to life, then I agree we should close and add a note in the docs for silent scroll and maybe also in the fixed toolbar page with the other list of issues.

[scottjehl]

k. it's not just silentscroll, fwiw, any native programatic scroll. But yeah, it happens there as a result.

Here's a bug we can reference outside jQM scottjehl/Device-Bugs#1