Created attachment 8793755 [details] testcase 1 STR: 1. Load attached testcase. 2. Scroll the scrollable area a bit (down and/or to the right) 3. Click the page body somewhere (to slightly increase the border-size & trigger a reflow). Or, resize your browser window. (We need to force a thorough reflow.) EXPECTED RESULTS: The abspos element shouldn't move (much) in step 3. (It should only move to reflect the subtle border-change on its parent.) ACTUAL RESULTS: The abspos element jumps outside of the scrollable thing in step 3, depending on how much you've scrolled it. We seem to think its static position should be adjusted based on the modified scroll-position -- but we only make that adjustment lazily (on an incremental reflow from other changes to the page - the border in this case). Moreover, on a page-reload (which preserves scroll position), it moves back inside the scrollable area. Chrome (version 55) gives EXPECTED RESULTS. This was originally reported as bug 1239619, but that bug's testcase was triggering reflows via "box-shadow" and so it became fixed when we stopped reflowing for "box-shadow" changes. I'm spinning off this new bug for the underlying issue, which still remains.
Created attachment 8793764 [details] testcase 2 (automated) Here's an automated version of the testcase. When the dynamic onload-triggered tweak happens, the "I should stay in blue area" div jumps to the upper-left (in response to the updated scroll postion), but it should not.
This is not a regression (or not a recent one). I can reproduce in nightlies as old as 2010-01-01 3.7a1pre (at least that old -- builds from 1 year before that won't run on my machine). And I can reproduce in recent Nightlies as well, e.g. 52.0a1 (2016-09-21) (64-bit)
Too late for firefox 52, mass-wontfix.