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.