[Bug]: StackingContext overflow in SplitView sidebar on MacOS

[pengooseDev]

Version

1.54.0-next

Steps to reproduce

I’d like to resolve the open-to-a-pull-request labeled issues that have been left unattended in UI mode, as well as a few others I came across during previous contributions—one by one, in small units.

Reproduction

MacOS (Issue)	Window11(No Issue)

On MacOS:

1. Run UI mode.  
2. Execute the tests.  
3. When one or more tests are running, stop the tests.  
4. Grab the right resizer of the test window and shrink its width.  
5. On Windows, the Actions and Metadata tabs truncate correctly, but on macOS the stacking context issue shown in the screenshot occurs.

Stacking Context

<SplitView>                                ← SC A: .split-view { position: relative }
 ├─ <div class="split-view-main">         ← Target to fix: .split-view-main { overflow: visible }
 │   └─ <SplitView>                       ← SC B: .split-view { position: relative }
 │       └─ <div class="split-view-sidebar">
 │           └─ <TabbedPane>
 │               ├─ <div class="toolbar">              ← SC C: .toolbar { position: relative }
 │               │   └─ :after (header box-shadow) { z-index:100 } ← 1. Header issue point
 │               └─ <div class="tab-content">           ← SC D: position: relative; overflow: hidden
 │                   └─ <ActionList>
 │                       └─ <ActionTreeView>
 │                           └─ <div class="tree-view-content">  ← SC E: position: relative; overflow: hidden auto
 │                               └─ <div class="tree-view-entry.selected">  ← z-index:10 (inside SC E)  ← 2. tab-content (on select) issue point

Affected Components

1. SplitView > TabbedPane > actionsTab > Toolbar

   • The toolbar’s box-shadow (introduced via .toolbar:after with z-index: 100) remains visible when the sidebar is shrunk.

2. SplitView > TabbedPane > actionsTab > ActionList > TreeView

   • The selected tree item (.tree-view-entry.selected with z-index: 10) overflows and leaves its background behind.

---

Proposed Solution

I propose adding a dedicated clipping rule for SplitView—similar to how TabbedPane works—so that its children are always clipped.

.split-view-main {
  display: flex;
  flex: auto;
  overflow: hidden; /* Added */
}

.split-view-sidebar {
  display: flex;
  flex: none;
  overflow: hidden; /* Added */
}

.tabbed-pane {
  display: flex;
  flex: auto;
  overflow: hidden;
}

If the team is okay with this approach, I’ll go ahead and create a PR :) I’d appreciate any feedback in a comment.

Expected behavior

It should not overflow when the width is shrunk.

Actual behavior

When the width is shrunk on macOS, the TabbedPane toolbar’s box-shadow and selected item background overflow instead of being clipped.

Additional context

No response

Environment

# MacOS (Issue)
  System:
    OS: macOS 15.4.1
    CPU: (12) arm64 Apple M2 Pro
    Memory: 1.86 GB / 16.00 GB
  Binaries:
    Node: 20.10.0 - ~/.nvm/versions/node/v20.10.0/bin/node
    Yarn: 4.2.2 - ~/.nvm/versions/node/v20.10.0/bin/yarn
    npm: 10.8.3 - ~/.nvm/versions/node/v20.10.0/bin/npm
    pnpm: 9.1.0 - ~/.nvm/versions/node/v20.10.0/bin/pnpm
  IDEs:
    VSCode: 0.51.2 - /usr/local/bin/code
  Languages:
    Bash: 3.2.57 - /bin/bash
---
# Window (Working as Expected)
  System:
    OS: Windows 11 10.0.26100
    CPU: (32) x64 AMD Ryzen 9 9950X 16-Core Processor    
    Memory: 36.97 GB / 61.66 GB
  Binaries:
    Node: 20.10.0 - C:\nvm4w\nodejs\node.EXE
    Yarn: 4.9.1 - C:\nvm4w\nodejs\yarn.CMD
    npm: 10.2.3 - C:\nvm4w\nodejs\npm.CMD
    pnpm: 10.11.1 - C:\nvm4w\nodejs\pnpm.CMD
  IDEs:
    VSCode: 0.50.7 - C:\Users\home\AppData\Local\Programs\cursor\resources\app\bin\code.CMD

[pengooseDev]

@agg23 If you think this approach to the issue is acceptable, I’d like to open a PR. However, if external contributions are currently restricted, I’ll wait and contribute later. Also, besides this issue, is UI mode open for contributions?

[agg23]

Can you provide a more specific repro scenario? I am unable to replicate in Chromium 138.0.7204.23 on macOS 15.5.

[pengooseDev]

@agg23

Can you provide a more specific repro scenario? I am unable to replicate in Chromium 138.0.7204.23 on macOS 15.5.

Reproduction

PW_HMR=1 npm run watch
PW_HMR=1 npm run ctest -- --ui

MacOS (15.4.1)

env

UI mode dev tool(Console)

navigator.userAgent
>> 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36'

chrome://version/

137.0.7151.104 (arm64) 

Since this issue only occurs on my end, please let me know if I should close the issue.

[mxschmitt]

I cannot reproduce with Google Chrome 138.0.7204.23. Do you think this is a recent regression or does it also reproduce with v1.52 or below?

[pengooseDev]

branch: release-1.49	branch: release-1.52

[email protected]

pengoose@Pengooseui-MacBookPro playwright % PW_HMR=1 npm run ctest -- --ui

> [email protected] ctest
> playwright test --config=tests/library/playwright.config.ts --project=chromium-* --ui

[email protected]

pengoose@Pengooseui-MacBookPro playwright % PW_HMR=1 npm run ctest -- --ui 

> [email protected] ctest
> playwright test --config=tests/library/playwright.config.ts --project=chromium-* --ui

[agg23]

I am able to reproduce, but not with the fidelity you present in your video. When I perform the dragging action quickly, I get at most a few frames of the overlapping UI, then it quickly snaps back to the correct state.

This suggests the cause is cascading React renders, and that your computer probably performs worse than ours, hence why you can see it reliably and we can't. A correct implementation would likely centralize the resize React state so it can all be updated simultaneously.

[mxschmitt]

I'm closing it for now since I wasn't able to reproduce on latest Chrome.