[LinearProgress] `color="action.disabled"` is crashing

<LinearProgress color="primary" /> works. <LinearProgress color="action.disabled" /> does not work (crash) <LinearProgress color="inherit" sx={{ color: "action.disabled" }} /> works as expected (workaround)

For example, These things work as expected: <Typography color="action.disabled">qwe</Typography> <Typography color="primary">qwe</Typography> <Typography color="primary.dark">qwe</Typography>

[oliviertassinari]

It’s to be notted that in these two examples:

<LinearProgress color="primary" />
<LinearProgress color="inherit" sx={{ color: "action.disabled" }} />

the color does not behave the same way. The color logic is vastly different, so I’m not sure that supporting:

<LinearProgress color="action.disabled" />

would be a step forward. Maybe the root problem is that we call the prop color. maybe if it was called differently, like:

<LinearProgress palette="primary" />

then it would be clear.

[socketpair]

Thanks for opening this issue @socketpair! @hbjORbj I agree with the OP that this inconsistency is worth addressing. I would also expect to be able to use the same values for the same props across these components, and would be frustrated when it doesn’t work. sweat_smile

I think we have three options here:

1. change the prop names (which could get ugly, because how would you rename something like color?)
2. make it so the props accept the same values (I don’t know how complex this might be behind the scenes)
3. leave the API as is and add a caution note in the docs (simplest solution but doesn’t address the underlying inconsistency)

1. Make components accept either variant of specifying color. I don’t vote for this option, but anyway.

I would advice make two new props:

1. paletteColor where one can specify “primary”, “secondary”, “warning”, and so on.
2. explicitColor where one can set values like “action.disabled”.
3. announce deprecation of bare color prop.