🦋 Changeset detected

Latest commit: b50cea3

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Preview URL

https://glide-core.crowdstrike-ux.workers.dev/tabs-overflow-update

The browser log message An error was thrown in a Promise outside a test. Did you forget to await a function or assertion? has re-appeared and I'm unable to resolve it so far. It happens when ow throws an error when an element other than a glide-core-tab-panel is placed in the default slot via the firstUpdated promise.

The browser log message An error was thrown in a Promise outside a test. Did you forget to await a function or assertion? has re-appeared and I'm unable to resolve it so far. It happens when ow throws an error when an element other than a glide-core-tab-panel is placed in the default slot via the firstUpdated promise.

This is a weird one. It appears to be casually unrelated to similar issues we've seen.

I compared Tab Group to other components that use owSlotType in firstUpdated. The only difference is that Tab Group changes state via its #onNavSlotChange handler. The issue goes away if you comment out those two lines.

If you look at the stack trace (first screenshot), you can see that onNavSlotChange_fn results in a firstUpdated call. Normally, firstUpdated is called directly by Lit and not via a slot change handler. And yet firstUpdated is only called once. So Lit must be batching the state change from #onNavSlotChange into the component's first update.

What's weird is, if you put a breakpoint on firstUpdated, you don't see #onNavSlotChange in the stack (second screenshot). You only see it when it's later logged in the console (first screenshot).

None of that answers the question of why the "unhandledrejection" handler is called.

My guess is that the state change in #onNavSlotChange and the resultant render batching is creating a nested promise somewhere in Lit. And so our try/catch isn't catching it. Something like this is what I assume is happening. Follow that link and open DevTools. Note that the rejection (Promise.reject()) inside the promise callback isn't caught by the try/catch block and so is picked up by the "unhandledrejection" handler.

Probably the best we can do is stub console.error.

Probably the best we can do is stub console.error.

9ecef80

If you look at the stack trace (first screenshot), you can see that onNavSlotChange_fn results in a firstUpdated call. Normally, firstUpdated is called directly by Lit and not via a slot change handler. And yet firstUpdated is only called once. So Lit must be batching the state change from #onNavSlotChange into the component's first update.

whoa, interesting.

My guess is that the state change in #onNavSlotChange and the resultant render batching is creating a nested promise somewhere in Lit. And so our try/catch isn't catching it. Something like this is what I assume is happening. Follow that link and open DevTools. Note that the rejection (Promise.reject()) inside the promise callback isn't caught by the try/catch block and so is picked up by the "unhandledrejection" handler.

Dang. Nothing to add here. But thanks for doing this and digging in!

Thank you @clintcs for looking into the above issue!