[Tracking Requested - why for this release]: Impossible to display the bottom of the page. Build Identifier: https://hg.mozilla.org/mozilla-central/rev/dbe4b47941c7b3d6298a0ead5e40dd828096c808 Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 ID:20160905030222 +++ This bug was initially created as a clone of Bug #1198135 +++ See Bug 1198135 Comment 39 and Bug 1198135 Comment 40. After landing Bug 1198135, the situation is worsen than before. Not enough scroll. Impossible to display the bottom of the page. Steps To Reproduce: 1. Open the following test pages 2. Scroll to bottom  http://www.keithclark.co.uk/labs/css-tests/tests/3d-transforms-overflow-scale-down/overflow-scaled.html  http://keithclark.co.uk/articles/practical-css-parallax/smooth-scroll/ Actual results: z-transformed and scaled content affects the scroll bounds of parent elements allowing a user to scroll beyond the bottom of the page. Not enough scroll. Impossible to display the bottom of the page. Expected results: The computed scroll area should match the height of the content.
Is a fix likely to land before 51 makes it into beta/dev edition releases? If not, would it not be better to back out of the changes made to fix bug 1198135 and revert to having excess overflow rather than clipping page content and making CSS parallax websites unusable?
Oops, looks like I broke the coordinate space we compute the overflow rect in, so that it became dependent on scroll pos. The existing test only covered scrollTop=0 so it wasn't caught. Funnily enough the code comment was correct, just wasn't what we were actually doing. This fixes the coordinate space issue and expands the test to check that it stays correct as we scroll. This fixes both test cases in this bug too.
Assignee: nobody → matt.woodrow
Attachment #8788281 - Flags: review?(dbaron)
(In reply to keith from comment #1) > Is a fix likely to land before 51 makes it into beta/dev edition releases? > If not, would it not be better to back out of the changes made to fix bug > 1198135 and revert to having excess overflow rather than clipping page > content and making CSS parallax websites unusable? If this fix doesn't make it in time for the merge, I'll make sure the regressing bug gets backed out of Aurora. We definitely don't want to ship this.
Tracking 51+ for this regression. I think we also want to track this one for 50, adding Ritu to the bug.
Comment on attachment 8788281 [details] [diff] [review] Use correct coordinate space r=dbaron if you've checked that using aScrollPort.x and .y is the right thing when the scrollframe has top/left border or padding (or a scrollbar on the left)
Attachment #8788281 - Flags: review?(dbaron) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/442ca1f2745e Move overflow rect into correct coordinate space when computing perspective overflows so that it's not affected by scroll position. r=dbaron
I've tested this in the latest nightly (51.0a1 (2016-09-15) (64-bit) OXS) and scrolling now behaves as expected. Fantastic work! It's great to see this now working correctly in Firefox. Unfortunately, I have found another issue. If you scroll resize the browser window, the scroll bounds don't appear to update until you next scroll. To reproduce: 1. visit: http://keithclark.co.uk/articles/practical-css-parallax/smooth-scroll/ 2. ensure the viewport width is >= 45em so that parallax is enabled. 2. scroll to the very bottom of the page. 3. increase the height of the browser window by resizing it vertically. 4. note the white area at the bottom of the page. 5. slowly scroll up and wait for the repaint. You can also see this effect if you open devtools and resize the devtools container.
Should I raise this an a separate bug?
Yes please! I''ll look into it.
Raised Bug 1303601 to cover this issue
You need to log in before you can comment on or make changes to this bug.