Why My ::after Horizontal Line Won’t Scroll: Debugging Layer Bugs in Chrome

Background

The horizontal line should have scrolled together with the page, but it stayed fixed. I learned about layer management from the Udacity browser rendering optimization course, which mentioned layers without detailed explanation. Today I encountered a bug caused by a layer.

Reproducing the Bug

The horizontal line should have scrolled with the page, but it did not:

Inspecting the Layer

The line is drawn using

::after

+

position:absolute

+

margin

, which forces the browser to create a separate rendering layer.

The course mentioned that

will-change

and

transform: translate

can hint the browser to create a layer (though the browser may ignore them).

Trying to add

will-change

or

transform

solved the visual problem, but the layer was not created—it was merged.

Although the issue was fixed, the layer merged instead of being a separate one.

Further inspection shows the Paint count changes while scrolling, but memory usage stays at 0 B because of

layerForVerticalScrollBar

. The page also has no visible scrollbar.

Even with the scrollbar disabled,

paint

and

composite

still occur.

Additional Observations

Adding

will-change

or

transform

resolves the visual glitch, but other issues appear:

The

.main

layer height changes with scrolling, and both

paint

and

composite

are triggered. This suggests scrolling triggers

paint

, not only

composite

as expected.

Comparing with another page shows scrolling still occurs on the root layer without triggering

paint

, which is puzzling.

Unresolved Questions

Question 1

In Blink,

transform

only results in

composite

. Why does

paint

still happen here?

Question 2

Some

::after

generated lines do not merge initially, while later ones do. Clicking the right scrollbar reveals partial layer merging without a full page repaint. The cause remains unclear.

If anyone has encountered similar issues or knows relevant articles, please share in the comments.

In hindsight, using

border

for the line would require extra

div

elements, increasing workload; the current approach with

padding

demonstrates the benefit of a view‑model‑driven layout.