Open Bug 1304710 Opened 8 years ago Updated 2 years ago

{inc} absolutely positioned element inside of scrollable area jumps to wrong position on incremental reflows

Categories

(Core :: Layout: Positioned, defect)

defect

Tracking

()

Tracking Status
firefox52 --- wontfix

People

(Reporter: dholbert, Unassigned)

References

Details

(Keywords: reproducible, testcase)

Attachments

(2 files)

Attached file 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.
Summary: absolutely positioned element inside of scrollable area jumps to wrong position on incremental reflows → {inc} absolutely positioned element inside of scrollable area jumps to wrong position on incremental reflows
Attached file 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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: