I opened a page on my site, where the side menu is position:fixed. Fennec does not obey that property correctly on scrolling. This is not an issue in Firefox. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 1.9.2a1pre) Gecko/20090626 Fennec/1.0b2 A screencast of the behavior is here: http://www.screencast.com/users/tmyoung/folders/Jing/media/0da38fe6-6d48-4f6b-89d5-b8ed05e79ec3

The page being tested is http://alyoung.com/My_Fathers_Captivity/

This bug is an artifact of the actual browser being 3x as tall as the screen display. The content isn't really scrolling, we're just moving our view on the content here.

This bug may be related to Fennec _not_ setting the scrollX/scrollY of the underlying browser as we pan the tiles.

Synchronizes the <browser> scrolling in _panScroller. Tested with several pages, including : http://twitter.com/MozMobile http://www.w3.org/TR/widgets-apis/ http://alyoung.com/My_Fathers_Captivity/

(In reply to comment #3) > This bug may be related to Fennec _not_ setting the scrollX/scrollY of the > underlying browser as we pan the tiles. Yes but... (In reply to comment #4) > Created an attachment (id=414508) [details] > fix > > Synchronizes the <browser> scrolling in _panScroller. The problem here is that we pause the rendering during a scroll which end with a strange behavior with the fix - the fixed menu is rendered at the end of the scroll (but that's ok I can live with that for now) In fact this patch belongs to bug 479862 which is the first one for that, and after to bug 499212 (which is probably a dup) and there is also a patch for it in bug 514623 (the first one) - and probably others This also the root cause of bug 524978. I think the main concern here is : * Are we sure to be loop free here? I mean are we sure that we are not going to enter into a loop with our handlePageScroll and this? * What is the downside of this patch in terms of performances?

Hopefully better patch : - prevents looping in handlePageScroll() - only makes a single scrollTo() at the end of the drag instead of scrollBy() during the pan. - takes zooming factor into account.

Comment on attachment 415137 [details] [diff] [review] new patch We have already tried this approach and reverted. It's not fast enough.

Has this been tested on a N900 and considered slow? I traced the repaint events and you only get a full repaint when the background is fixed. In the case of a page like http://alyoung.com/My_Fathers_Captivity/ (with a fixed menu hovering on the right side) it's not so massive.

Can we have another look at this? The discussion seems to have dropped off.

I'd like to dup this to bug 607417. Please let me know if there are reasons not to.

I would recommend having Bug 607417 block this so it is easier to verify after the issues in that bug are resolved, since this also might merit it's own automated testcases or litmus testcases.

Can we close this bug or is it still happening?

I still see it happening on http://alyoung.com/My_Fathers_Captivity/

This works for me on trunk.