Steps to reproduce:

1. Be on macOS.
2. Enable the prefs gfx.webrender.all, gfx.webrender.compositor (requires restart), and gfx.core-animation.tint-opaque (restartless).
3. Pay attention to the amount of redness on the screen.

Expected results:
The active tab and the back button should be drawn into the same red layer as the rest of the chrome.

Actual results:
The active tab and the back button are drawn into another red layer that goes on top of the rest of the chrome. When the statusbar appears (when a link is moused over), there's a big red layer that covers the majority of the browser window.

Most of the browser chrome is "behind" the content area, in z-order. Elements that are "in front" of the content area, in z-order, go into a separate layer. (The fact that these elements don't overlap the content area is not taken into account by WebRender, and we should keep it that way.)

We should apply some z-index declarations in browser CSS, so that we have the following order:

1. Bottom layer: The window background and all elements in the browser chrome that do not overlap the content area. This should include the active tab and the back button.
2. Middle layer: The <browser> for the tab contents
3. Top layer: Elements from the browser chrome that can overlap the tab contents, such as the focused URL bar and the URL bar autocomplete dropdown.

Would there be a way to write an automated test that ensures this won't regress?

Probably. I'm still working out whether it actually works reliably... there's evidence that the combination of Retained Display Lists and WebRender's layerization algorithm don't handle z ordering the way we want and that just setting the right z-indexes won't reliably achieve the intended optimization.

@Markus: Should this block mac release?