Event target stack incorrect when `wa-page` is imported

[tpluscode]

Which package(s) are affected?

SSR (@lit-labs/ssr)

Description

I render a page where my elements are sharing some data using @lit-labs/context. When I put them in Web Awesome wa-page, I found that the context stepped propagating.

I traced it to issue with event targeting where the event target stack is incorrect, thus causing the event to never reach the right parent

Reproduction

https://gist.github.com/tpluscode/3e5bdc0768489f8376379b055ddcfe6f

Workaround

I found none

Is this a regression?

No or unsure. This never worked, or I haven't tried before.

Affected versions

lit@3.3.1 @lit-labs/ssr@3.3.1 @lit-labs/context@0.5.1

Browser/OS/Node environment

• Brave 1.84.139 Chromium: 142.0.7444.163
• node 20.19.4
• npm 10.8.2
• macOS 15.3.2

[tpluscode]

I managed get some more details on this. Looks like the issue is when processing slots.

tl;dr;, the op 'slot-element-close' in render-value.js hits more times than 'slot-element-open'. Or, to be more precise, the 'slot-element-open' is wrongly skipped so that some slots are not appended to the target stack and then wrong elements are removed.

My first suspect are dynamic slot names as seen here https://github.com/shoelace-style/webawesome/blob/d2b5613e85074acdaf774690c65ad9ffa95750f5/packages/webawesome/src/components/page/page.ts#L346-L357

When I make them static (and more below), the target stacks look more correct but the event is still not propagated right. There is still an additional 'slot-element-close' which removes wrong element. I pushed a patch with some more console.log calls to the gist. When you run it, you'll see for example this

now LIT-SERVER-ROOT -> EX-PAGE -> WA-PAGE -> WA-DRAWER
POP SLOT - last element is SLOT
POP SLOT - last element is SLOT
POP SLOT - last element is SLOT
POP SLOT - last element is SLOT
POP SLOT - last element is WA-DRAWER
POP SLOT - last element is SLOT
POP SLOT - last element is SLOT
POP WA-PAGE
now LIT-SERVER-ROOT -> EX-PAGE
POP SLOT - last element is SLOT
POP EX-PAGE
now LIT-SERVER-ROOT
LIT-SERVER-ROOT -> PAGE-HEADER

See how wa-drawer is removed from the stack at the wrong moment. This ultimately causes my context consumer element page-header to become "detached" from its context provider element ex-page

[justinfagnani]

@tpluscode thanks for the investigation. Looking at our SSR operations for slots, I can see that we don't support dynamic slot names.

On template prep for slots:

lit/packages/labs/ssr/src/lib/render-value.ts

Line 487 in 57e052a

name: node.attrs.find((a) => a.name === 'name')?.value,

On template prep for slotted elements:

lit/packages/labs/ssr/src/lib/render-value.ts

Line 460 in 57e052a

name: node.attrs.find((a) => a.name === 'slot')?.value,

These both assume a static name or slot attribute. I wonder if your example has any dynamic slot attributes on elements, and that's the remaining problem?

I don't see why we can't support dynamic values here, but there are probably some tricky bits.

• We might need to rethink the slotted-element-open operation a bit, since it comes before the custom-element-open operation where we actually make the element renderer instance and attribute-part where we evaluate the bindings. We might have to mark a slotted-element-open operation as having a dynamic name, then special case slot=${...} bindings to find the associated slotStack item and set its name.

  I wonder if we actually need separate slotted-element-open and custom-element-open operations too, since we only push on to the slotStack for custom elements?

• Similar thing forslot-element-open: we need to mark the ones with dynamic slot names, then when we see a name attribute, look up the slot element and set its name.

I think these things will necessarily be done before any events will be fired that require a proper slot setup, but if not we can throw en error if an event traverses through an un-finalized slot or slotted element.

[justinfagnani]

cc @kyubisation

[tpluscode]

I wonder if your example has any dynamic slot attributes on elements, and that's the remaining problem?

Not 100% certain, but I don think there are any such cases here