fix: Wrong z-axis order for fluent-accordion in @fluentui/webcomponents

[davidxuang]

🐛 Bug Report

Wrong z-axis order for overlaying controls (e.g. fluent-select) inside fluent-accordion.

💻 Repro or Code Sample

<fluent-accordion>
  <fluent-accordion-item expanded>
  <label slot="heading">Encryption</label>
  <!-- ... -->
  <div class="flex-column">
    <label id="cipher">Cipher</label>
    <fluent-select aria-labelledby="encryption">
        <fluent-option value="0">None</fluent-option>
        <fluent-option value="1" disabled>AES-128-GCM</fluent-option>
        <fluent-option value="2" disabled>AES-256-GCM</fluent-option>
        <fluent-option value="3" disabled>ChaCha20-Poly1305</fluent-option>
    </fluent-select>
  </div>
  <!-- ... -->
  </fluent-accordion-item>
  <fluent-accordion-item>
  <label slot="heading">Security</label>
  <!-- ... -->
  </fluent-accordion-item>
</fluent-accordion>

🤔 Expected Behavior

ListBox of Select should be over the accordion heading stuffs.

😯 Current Behavior

💁 Possible Solution

Currently, Accordion heading has a z-index of 2 while that of ListBox of Select is 1, so this may be fixed by just modifying CSS.

🔦 Context

Building a form dialog with classified options with Blazor.

🌍 Your Environment

• OS & Device: Windows 11
• Browser Microsoft Edge 95.0.1020.30, Mozilla Firefox 93.0
• Version 2.0.0

[chrisdholt]

Thanks for this bug @davidxuang, I've moved this to the Fluent repo where the styles live for tracking.

This is an interesting issue and it's probably not as straight forward as this. The select overlaying the accordion, is most likely expected because of how the native select currently works - presenting the listbox on the top layer regardless of what content it overlays. Currently this behavior isn't made available from the web platform and so z-index and stacking context is likely the reason this looks like the bug is that it should overlay the accordion header. However, I think this is a weird stacking context issue and the expected behavior here is currently that this would grow the height of the accordion item - at least based on the current expected POR.

We are tracking behavior to use Anchored Region for select to accomplish this here: microsoft/fast#4791. Beyond that we're also working to get this behavior exposed in the platform via Open UI. The proposal can be found here and the most recent issues and discussion can be found here: https://github.com/openui/open-ui/issues?q=is%3Aissue+is%3Aopen+label%3Apopup.

For now I think we need to audit to ensure that each components aren't making assumptions about their surroundings in ways that don't make sense. I see some various usage of z-index that looks either outdated or newly added perhaps incidentally as part of an update.

We should be able to get a quick fix out to address the expected behavior for this and then audit the rest quickly.

[robarbms]

I did some digging and found the problem in fluent-accordion-item. The actuator for expanding and collapsing each accordion item is a button that is between start, end and the icon elements. It doesn't span the full width but is trying to capture clicks for the entire header. They used a clever trick of adding a button::before pseudo element positioned absolute to span the entire width of the header. This was however covering the start, end and icon and swallowing clicks for these. To prevent this, z-index: 1 was applied to the pseudo element and z-index: 2 on start, end and icon elements. This forced them on top but caused header elements to appear above other elements unexpectedly.

The accordion item was built so that z-index isn't actually needed. Button comes before start, end and icon in the DOM and using grid, start is positioned left of the button. It was just the position: absolute on the button::before pseudo element that forced it above everything. Adding to position: relative to start, end and icon removes the need for z-index. This pops those elements above the pseudo element since they come after it in the DOM order.