Gecko : 7dc9265ed90037fbd273a05d322637931191d87a Gaia : 0035590eefc1ac6cfc05cfa868ed646f9f545e0c 1. launch browser 2. go to http://people.mozilla.com/~nhirata/html_tp/ 3. select a web page 4. hit the back button 5. scroll Expected: scrolling down Actual: bouncing back to where you started from.
Need info for retesting
5 years ago
blocking-b2g: --- → koi?
Naoki, why did you nominate this? It sounds like expected behavior
Created attachment 805673 [details] bug909525.mov Please see attached video. the Actual result shows the web page bouncing up and down when trying to pan downwards to see the rest of the page. Basically, you can't scroll down.
Sounds like an APZC regression.
Component: Gaia::Browser → Graphics: Layers
Product: Boot2Gecko → Core
Version: unspecified → Trunk
I recall filing this bug as soon as the APZ stuff landed. I made my own build that day.
Regression Window! The issue doesn't reproduce on Buri: Build ID: 20130730030200 Gecko: http://hg.mozilla.org/mozilla-central/rev/3d40d270c031 Gaia: ba5ff211fbf6a930326cc6a0d4a1205a7528630b Platform Version: 25.0a1 The issue reproduces on Buri: Build ID: 20130731030205 Gecko: http://hg.mozilla.org/mozilla-central/rev/c2b375f3a909 Gaia: 9bfceaa90e8b92a379432b67121afa3cd3f14c90 Platform Version: 25.0a1 With some builds able to scroll down but not able to scroll up
Assignee: nobody → bugmail.mozilla
Created attachment 806369 [details] [diff] [review] Patch
I suspect that backing out part 2 of bug 895905 might also fix this. That might be a cleaner way to do this; I will verify if that actually fixes this or not.
Yeah backing out part 2 of bug 895905 also fixes this. I would lean towards doing, what do you guys think?
Do we still want to stop treating the root id as special? Can we? If so, do we have a plan for that? If that is still the goal then I'm less concerned about how we hack around it in the mean time.
Yeah I think long term we would still like to stop treating it as special. Bug 900092 is on file for getting rid of it entirely if we can.
(But I don't have a concrete plan for accomplishing that)
Comment on attachment 806369 [details] [diff] [review] Patch Review of attachment 806369 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/ipc/TabChild.cpp @@ +356,5 @@ > > + // Note that we cannot use FindScrollableFrameFor(ROOT_SCROLL_ID) because > + // it might return the root element from a different page in the case where > + // that page is in the bfcache and this page is not run through layout > + // before being drawn to the screen. Hence the code blocks below treat Why don't non-ROOT_SCROLL_ID id's have this problem?
ROOT_SCROLL_ID is the only ScrollId that's reused across documents. All the other ones are unique because of the incrementing counter.
Comment on attachment 806369 [details] [diff] [review] Patch Review of attachment 806369 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. I agree that the proper solution is to eventually remove special handling of ROOT_SCROLL_ID, and I think this patch is more in line with that than reverting part 2 of bug 895905 (in particular, I think we'll want to keep the call to nsLayoutUtils::FindOrCreateIDFor() in nsDisplayList::PaintForFrame(), and reverting part 2 of bug 895905 would remove that). That said, I have no strong feelings about it.
Attachment #806369 - Flags: review?(botond) → review+
Attachment #806369 - Flags: review?(tnikkel) → review+
Comment on attachment 806369 [details] [diff] [review] Patch [Approval Request Comment] Bug caused by (feature/regressing bug #): combination of previous bugs landed in 26/b2g-1.2. User impact if declined: on some pages, navigating away and going back breaks scrolling Testing completed (on m-c, etc.): locally Risk to taking this patch (and alternatives if risky): i would say low risk but this code has proven to be quite brittle in the past. more testing on this would help mitigate risk String or IDL/UUID changes made by this patch: none
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Comment on attachment 806369 [details] [diff] [review] Patch koi+ blockers have automatic approval
status-b2g-v1.2: --- → fixed
status-firefox26: --- → fixed
status-firefox27: --- → fixed
You need to log in before you can comment on or make changes to this bug.