500700 - Fennec does not render position:fixed elements well while scrolling

Status: RESOLVED DUPLICATE of bug 607417

(Firefox for Android Graveyard :: General, defect)

Description

[Tanner M. Young [:tmyoung]]

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

Comment 1

[Tanner M. Young [:tmyoung]]

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

Comment 2

[Ben Combee (:bcombee)]

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.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 4

[Fabrice Desré]

Attachment: fix

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/

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

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

Comment 6

[Fabrice Desré]

Attachment: new patch

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 7

[Benjamin Stover (:stechz)]

Comment on attachment 415137 [details] [diff] [review]
new patch

We have already tried this approach and reverted.  It's not fast enough.

Comment 8

[Fabrice Desré]

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.

Comment 10

[Aakash Desai [:aakashd]]

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

Comment 11

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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

Comment 12

[Tanner M. Young [:tmyoung]]

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.

Comment 13

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Can we close this bug or is it still happening?

Comment 14

[Martijn Wargers (dead)]

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

Comment 15

[Matt Brubeck (:mbrubeck)]

This works for me on trunk.