892088 - [browser] the content jumps after scrolling

Status: RESOLVED DUPLICATE of bug 880578

(Firefox OS Graveyard :: General, defect)

Description

[Julien Wajsberg [:julienw]]

STR:
* open any page (for example: http://getfirefox.com)
* scroll down like you would to to read the website (so by a few lines, then again by a few lines)

Expected:
* the content stays at the place you stopped scrolling

Actual:
* the content "jumps" up by an amount that is not constant, but when you scroll down only a little, it very often jumps up by a similar amount, that is extremely frustrating.

I'm filing that under "gaia::browser" but of course this is probably an underlying issue.

Comment 1

[Julien Wajsberg [:julienw]]

Nominating leo? because this is a regression and we can't let a phone out with this bug.

As good commit hash, you can try the one from bug 833795 where a similar bug was fixed.

Note that I use a b2g18 gecko with a master gaia. Qawanted to check that it happens on a "real" v1-train setup.

Comment 2

[Natalya Kot [:nkot]]

(In reply to Julien Wajsberg [:julienw] from comment #1)
> Note that I use a b2g18 gecko with a master gaia. Qawanted to check that it
> happens on a "real" v1-train setup.

yes, it happens on "real" v1-train :), let me find a regression window

Comment 3

[Jason Smith [:jsmith]]

This might be a dupe of bug 891180.

Comment 4

[Natalya Kot [:nkot]]

The regression window on bug 891180 is: 
  2013-07-02-10-47-56 - no repros 
  2013-07-02-23-02-06 - repros

but talking about this bug, scrolling web is still not smooth on build 2013-07-02-10-47-56, it still jumping, especially when scrolling at the top of the screen or when reaching the very bottom, though it looks better comparing to 2013-07-02-23-02-06 build, 

I think the regression window here is:

  Build  2013-06-26-07-02-11 - Works fine
  Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/855297ec671e
  Gaia   e6666a2135244f75ff793aae790feeddbeae8832

  Build  2013-06-26-08-55-59 - Broken
  Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/c1a491ca5b62
  Gaia   f26c625afa5e1e53cbe900f09b93108d88503a1d

Comment 5

[Jason Smith [:jsmith]]

This is a regression from either bug 878142 or bug 858937 in reference to the 6/26 regression range. The 7/2 regression range reference is likely a regression from bug 876542.

Comment 6

[Nick Cameron [:nrc]]

(In reply to Jason Smith [:jsmith] from comment #5)
> This is a regression from either bug 878142 or bug 858937 in reference to
> the 6/26 regression range. The 7/2 regression range reference is likely a
> regression from bug 876542.

As far as I know, there should be no CSS animations/transitions involved in scrolling the browser window and so neither of the bugs looks likely. But in bug 858937, the first patch changes how we get the frame for styling for many elements, so I guess that seems slightly more likely to have caused this bug. dbaron - does that sound possible?

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The first patch should have been a pure refactoring.

Sounds like we need regression range down to the changeset.

Comment 8

[Jason Smith [:jsmith]]

Confirmed that the backout of bug 876542 did not fix this bug.

Comment 9

[Jason Smith [:jsmith]]

Did another analysis of the push log. The only other bugs that might have caused this could have been some of the work done on bug 796722 or bug 831237. Including Anthony on the cc list in case he thinks this is a regression from one of those bugs.

But yeah, I agree we need to bisect this find the exact changeset.

Comment 10

[Nick Cameron [:nrc]]

Just needinfo-ing k17e so he sees this. He goes on PTO after today and it would probably be good to get some info from him before he leaves.

Comment 11

[bhavana bajaj [:bajaj]]

This appears to be a fallout from a leo+ bug that missed a patch landing, depending on how risky the patch is or we will fix the issue or may do a backout of the original issue .

[The above awaits Jason's testing on a try build to have the right dependencies]

Comment 12

[Jason Smith [:jsmith]]

Putting needinfo on me for comment 11 to look into this.

Comment 13

[Jason Smith [:jsmith]]

Turns out my original plan I was going to try here isn't going to work - I was going to try spin a try build with b2g18 including the patch in bug 831237. However, we currently do not support try builds on b2g18.

So I think the next steps here that would be better would be to have someone on the development team build a b2g18-specific patch for bug 880578 and test to see if this still reproduces.

Chris - Could you help out on this?

Comment 14

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #13)
> Turns out my original plan I was going to try here isn't going to work - I
> was going to try spin a try build with b2g18 including the patch in bug
> 831237. However, we currently do not support try builds on b2g18.
> 
> So I think the next steps here that would be better would be to have someone
> on the development team build a b2g18-specific patch for bug 880578 and test
> to see if this still reproduces.
> 
> Chris - Could you help out on this?

Both bug references above should be meaning to reference bug 880578 btw.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I looked into this a bit. I found that we jump back because AsyncPanZoomController::NotifyLayersUpdated gets called, while we're in the NOTHING state just after a pan operation, which resets mFrameMetrics.mScrollOffset to whatever was in the metrics passed in the aViewportFrame parameter.

Seems to me quite possible that the main thread could send a layer update with a slightly stale scroll offset, which the APZC receives just after the its panning operation has ended, which trashes its scroll offset. Is there anything in the code already which is supposed to prevent that?

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Note, my testing is on the b2g18 branch.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I should read bug comments more carefully. Indeed, backporting the fix for bug 880578 fixes this bug. Sorry Jason! I'll attach the patch over there.

Comment 18

[Kartikaya Gupta (email:[e-mail])]

Clearing needinfo on me since it looks like you figured it out. Also for reference this sounds related to bug 859929 which Botond is working on.

Comment 19

[Wayne Chang [:wchang]]

Duping this bug per comment 17. Please reopen if i misunderstood the comment.

thanks.