[app bar] Box background covers AppBar shadow

[majate]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

Placing a Box component with a background color after an AppBar (with position="static") “covers” the shadow of the elevated AppBar. Furthermore, modifying the zIndex of the Box did not change how the shadow of the AppBar was cast (or not cast) onto it.

Expected behavior 🤔

I would have assumed that an elevated object (such as the AppBar) is above any non-elevated objects (such as a Box component) and therefore casts its shadow onto the non-elevated objects.

Steps to reproduce 🕹

Here is a simple example:
https://codesandbox.io/s/appbar-shadow-issue-sqq694

Open the example and toggle the switch to see the shadow of the AppBar appearing and disappearing when the background color of the Box is changed between “transparent” and “background.paper”.

Context 🔦

When creating a simple application for a school project I used a couple of your templates and examples as a starting point:

• The App bar with responsive menu example for the header.
• The checkout template as base for the content of one subpage.
• The album template as base for the content of another subpage.

I later realized that the AppBar shadow was only visible on the Checkout based subpage, which was unexpected. After some testing I realized that the main difference between the templates was that the Album template used boxes with background colors.

I now also see that the Album template uses an AppBar with position="relative" instead of position="static" (as the AppBar example my header is based on) and that their AppBar shadow is visible, so the problem seems to be related to position="static".

Your environment 🌎

See the codesandbox example (it uses the same environment as your template)

[majate]

I guess this problem may be related to problems mentioned in #7994

[siriwatknp]

I don't think this is a problem or an issue because this is how CSS works. What we can do is add an info to the demo with <AppBar position="static"> that the app bar does not create new stacking context (z-index does not work)

[majate]

Ah, that’s reasonable. I haven’t worked much with z-indexing in plain CSS before, so didn’t realize that the different position options also affected that.

Since multiple AppBar demoes uses position=”static”, it would be nice if the documentation included some note mentioning that this option causes the AppBar to not handle elevation and z-indexing properly. Especially since AppBars are elevated per default.

[oliviertassinari]

So if I understand it correctly, our demos in the docs are sub-optimal, they could be using position="relative" to avoid this case. We could do, e.g.:

diff --git a/docs/data/material/components/app-bar/ButtonAppBar.tsx b/docs/data/material/components/app-bar/ButtonAppBar.tsx
index 180c238ecd..9821067ddf 100644
--- a/docs/data/material/components/app-bar/ButtonAppBar.tsx
+++ b/docs/data/material/components/app-bar/ButtonAppBar.tsx
@@ -10,7 +10,7 @@ import MenuIcon from '@mui/icons-material/Menu';
 export default function ButtonAppBar() {
   return (
     <Box sx={{ flexGrow: 1 }}>
-      <AppBar position="static">
+      <AppBar position="relative">
         <Toolbar>
           <IconButton
             size="large"

I introduced this regression to the docs in #7049.

[zekson266]

I've changed AppBar position="relative", add sx={{ zIndex: 1 }} and add sx={{ zIndex: 0 }} to the component. Works only using sx, if added zIndex={1} - doesn't work.