CompositionLocalProvider related RuntimeError: illegal cast

[bnorm]

Describe the bug

It seems that a CompositionLocalProvider nested within another CompositionLocalProvider is causing a crash on K/Wasm.

@OptIn(ExperimentalComposeUiApi::class)
fun main() {
    ComposeViewport(document.body!!) {
        MaterialTheme { // Anything that is or uses CompositionLocalProvider
            Example { // Important! MaterialTheme used directly works
                Text("Hello, World!")
            }
        }
    }
}

@Composable
fun Example(content: @Composable () -> Unit) {
    MaterialTheme {
        content()
    }
}

• Note that the nested CompositionLocalProvider must be within another Composable.
  • If there are 2 within the same Composable function, the application loads without issue.
  • Nested MaterialThemes does not trigger crash, not sure why. Maybe because it's from a library?
• Most interesting to me, is that the provided values do not need to be of the same type.
  • CompositionLocalProvider(LocalString provides "test") and CompositionLocalProvider(LocalInt provides 1) would also cause the same crash.

Affected platforms

• Web (K/Wasm) - Canvas based API
  • Chrome Version 126.0.6478.127 (Official Build) (arm64)

Versions

• Libraries:
  • Compose Multiplatform version: 1.7.0-alpha01 (tested with 1.6.11 and it works correctly)
• Kotlin version: 2.0.0

To Reproduce Sample project using https://kmp.jetbrains.com/ : ComposeWasmCrash.zip

Expected behavior App to load and "Hello, World!" to be displayed.

Screenshots

From the browser console:

Uncaught (in promise) RuntimeError: illegal cast
    at <ComposeWasmCrash:composeApp>.androidx.compose.runtime.CompositionLocalProvider (composeApp.wasm:0x311483)
    at <ComposeWasmCrash:composeApp>.androidx.compose.material.PlatformMaterialTheme (MaterialTheme.js.kt:26:5)
    at <ComposeWasmCrash:composeApp>.androidx.compose.material.MaterialTheme$lambda$lambda.invoke (MaterialTheme.kt:80:13)
    at <ComposeWasmCrash:composeApp>.androidx.compose.material.MaterialTheme$lambda$lambda.invoke (composeApp.wasm:0x50ecd3)
    at <ComposeWasmCrash:composeApp>.androidx.compose.runtime.internal.ComposableLambdaImpl.invoke (composeApp.wasm:0x365d61)
    at <ComposeWasmCrash:composeApp>.androidx.compose.material.ComposableLambda$invoke$ref.invoke (composeApp.wasm:0x50ed38)
    at <ComposeWasmCrash:composeApp>.androidx.compose.material.ComposableLambda$invoke$ref.invoke (composeApp.wasm:0x50eda1)
    at <ComposeWasmCrash:composeApp>.androidx.compose.runtime.CompositionLocalProvider (composeApp.wasm:0x311491)
    at <ComposeWasmCrash:composeApp>.androidx.compose.material.ProvideTextStyle (Text.kt:399:5)
    at <ComposeWasmCrash:composeApp>.androidx.compose.material.MaterialTheme$lambda.invoke (MaterialTheme.kt:79:9)

[HamaniKhalil]

Ha, I was about to create an issue like this one ! I confirm that this is happening in compose 1.7.0-alpha01. Because I had about the same stacktrace and it was fixed only by downgrading to compose 1.6.11 !!! In my case the CompositionLocalProvider that crashed was something related to Surface from Material3, also tried to downgrade to Surface from Material i.e. Material 2.

[PMARZV]

A workaround is here https://github.com/JetBrains/compose-multiplatform/issues/5045#issuecomment-2210683603 (my problem was with Surface Material 3)

[eymar]

Hi @bnorm! Thanks for reporting!

Indeed, 1.7.0-dev and alpha (and all furter builds) won't work in web with kotlin 2.0.0, because the compose compiler for web for 2.0.0 doesn't support a new API added in compose runtime 1.7.0

For now, you can use kotlin:

• 2.0.10-RC-515 with the default compiler plugin
  • or 1.9.24 with compose compiler 1.5.14.1-beta02

The fix can't be backported to 2.0.0, it will be available only in kotlin 2.0.10.

[eymar]

I'm closing this one as I see no particular actions on our side, except suggesting to use a correct Kotlin version. Feel free to add more questions or reopen if needed.

[bnorm]

I can confirm that version 2.0.10-RC-515 does indeed my issue. Thanks!

I did test this with 2.0.20-Beta1 and the issue was present there. I'm guessing the issue will be fixed in the next 2.0.20 release as well?

[eymar]

Yes, the fix was implemented a bit a later than 2.0.20-Beta1.

2.0.20-Beta2 should have it.

[okushnikov]

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.