Closed Bug 1014997 Opened 6 years ago Closed 5 years ago
[Vertical Homescreen] Bouncing continues after tapping the home button while flywheel scrolling
Build Information Gaia ef66efa34ed8a559c8998bde688fae88eb943a7a Gecko https://hg.mozilla.org/mozilla-central/rev/b40296602083 BuildID 20140522040230 Version 32.0a1 ro.build.version.incremental=94 ro.build.date=Tue May 20 09:29:20 CST 2014 Step to reproduce With 3 column layout with more than 30 icons (eng build for instance), flick down twice to start flywheel scrolling Immediately (before the end of scrolling), hit the home button Let the homescreen finish the animation Actual result After tapping the home button, the vertical position is not set to the top because of the animation Expected result Tapping the home button should bring you to the top
I don't have idea how to stop the inertia of the scroll that is being performed. Any idea mates?
The root cause of this is actually because we do not yet have the CSSOM smooth scrolling spec implemented yet (bug filed but that will not make 2.0). In the meantime, we might be able to try to either delay the home button until after a scroll, or remove the animation all together. Even if we delay I feel it might still not be perfect though - racing APZ in client Js is never a good option :-/
(In reply to Kevin Grandon :kgrandon from comment #2) > The root cause of this is actually because we do not yet have the CSSOM > smooth scrolling spec implemented yet (bug filed but that will not make 2.0). > > In the meantime, we might be able to try to either delay the home button > until after a scroll, or remove the animation all together. Even if we delay > I feel it might still not be perfect though - racing APZ in client Js is > never a good option :-/ Delaying seems painful. The CSSOM bits will solve that but the core issue is that setting scrollLeft/scrollTop from JS should just stop any APZ inertia. Which is a separate issue. My understanding is that this should work with/without CSSOM smooth scrolling thing. Kats, any opinion ?
Flags: needinfo?(21) → needinfo?(bugmail.mozilla)
I suppose that could be an option, but ideally we would use an API to scroll to the top of the page, not manual scrollTop setting.
(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #3) > Delaying seems painful. The CSSOM bits will solve that but the core issue is > that setting scrollLeft/scrollTop from JS should just stop any APZ inertia. > Which is a separate issue. As far as I know setting scrollLeft/scrollTop should abort APZ inertia. Is this not happening? If it isn't happening it's a bug.
Basically this is the algorithm: https://github.com/mozilla-b2g/gaia/blob/master/dev_apps/home2/js/app.js#L73 and according to code we are using window.scrollBy(). Should it stop the inertia? Thanks a lot
Yes, scrollTo, scrollBy, scrollLeft, scrollTop - all of them should abort the APZ inertia. If this bug is only about that issue then feel free to move it to Core::Panning & Zooming and I can take a look. If this bug includes other issues then please file a separate bug for this problem.
Component: Gaia::Homescreen → Panning and Zooming
Product: Firefox OS → Core
Done Kats. This bug does not include anything more, thanks a lot
Assignee: nobody → bugmail.mozilla
Pretty simple fix.
Attachment #8430894 - Flags: review?(botond)
See Also: → 921020
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Mass modify - set status-b2g-v2.0 fixed for fixed bugs under vertical homescreen dependency tree.
You need to log in before you can comment on or make changes to this bug.