1918489 - Absolutely positioned child of inline container disappears when you click

Status: NEW

(Core :: Web Painting, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Load attached testcase.
2. Click the page (location probably doesn't matter, but let's say: click just above the top-center of the pink bordered box)

ACTUAL RESULTS:
The cyan element disappears.

EXPECTED RESULTS:
The cyan element should not disappear.

NOTES:
After it's disappeared, it reappears if you force a repaint by e.g. resizing your window or alt-tab. But then it will usually disappear if you click again or force another repaint.

This is a regression. Regression range:
Last good revision: 0ceabd10aac2272e83850e278c7876f32dbae42e (2018-04-16)
First bad revision: 789e30ff2e3d6e1fcfce1a373c1e5635488d24da (2018-04-17)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0ceabd10aac2272e83850e278c7876f32dbae42e&tochange=789e30ff2e3d6e1fcfce1a373c1e5635488d24da

The layout looks the same before/after that regression range -- it's just this painting issue (with the element disappearing) that was introduced.

In that range, I'm not sure offhand what the regressor would be, but I'm guessing it's one of the display list changes:

Matt Woodrow — Bug 1453668 - Restrict the retained display list stacking context optimization to frames that are also containing blockks for position:fixed. r=miko
Matt Woodrow — Bug 1453942 - Invalidate if any content ancestor of the display item frame is modified, not just frame tree ancestors. r=miko
Matt Woodrow — Bug 1452805 - Make sure we rebuild contents infront and behind stacking contexts if their size might have changed. r=miko
Matt Woodrow — Bug 1452225 - Rebuild the whole subdoc when the caret changes, but don't invalidate the nsDisplaySubdocument. r=miko

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's the testcase here -- this is from me attempting to reduce a testcase for bug 1911066. I think this might be why the slide-counter doesn't initially paint in that bug, though I'm not entirely sure.

(The main issue in that bug is something else -- the geometry of the abspos containing block.)