[缺陷] 会话面板内的插件模态无法逃离所在 pane 的层叠上下文（z-index 99999 输给兄弟 pane 的 z-index 8）

[chenshi723]

摘要

插件渲染在会话区里的弹窗，无法盖住兄弟 pane 的内容。它写的 z-index: 99999 完全失效，于是另一个 pane 里一个 40px 宽、看不见的拖拽手柄（z-index: 8）会吃掉本该属于弹窗的点击。同一个元素在触屏上还会留下一条常亮的悬停指示条。

环境

• @deepseek-ai/dsh 0.1.5-rc.2（DSHA 安卓 App 内置，App 版本 0.1.5-rc2 / code 129）
• 安卓 16 平板，WebView 视口 1238×787 CSS px，devicePixelRatio 2.5
• pointer: coarse、hover: none（纯触屏）
• 涉及包：dsh-client-ui-conversation

复现步骤

1. 插件把一个 position: fixed 的对话框 + 遮罩渲染进 conversation.composer.dock 插槽（对话框 z-index: 99999，遮罩 99998）；
2. 打开这个对话框；
3. 点击落在 CSS x 366–406 区间内的任意控件 —— 那里正是 div.wSkVaW_widthHandle 的位置。

实际结果

点击被 div.wSkVaW_widthHandle 吃掉（40px 宽、position: absolute; z-index: 8），尽管对话框是 position: fixed; z-index: 99999 且在视觉上位于最上层。用户能感知到的现象是：「点那几个标签不灵敏，得点好几下」。

在该手柄中心用 document.elementsFromPoint 实测的绘制顺序（从最上层到最下层）：

div.dshadb_scrim z:99998 fixed <- 插件对话框的遮罩
div.EvIC1a_scroll z:auto static
div.EvIC1a_root z:auto relative
div.wSkVaW_viewArea z:auto static
div.wSkVaW_scrollBody z:auto static
div.wSkVaW_body z:auto relative
div.wSkVaW_root z:auto relative

从两个元素各自向上找到最近的「自成层叠上下文的祖先」：

模态的上下文根 = div.dshadb_scrim（它自己的遮罩）
手柄的上下文根 = div.wSkVaW_body
=> 两者不在同一个层叠上下文

期望结果

一个 position: fixed 且 z-index: 99999 的对话框，应当绘制并命中测试于 z-index: 8 的 absolute 元素之上，并且不应被兄弟 pane 的内容遮挡。

推测的根因

dsh-client-ui-conversation 中有这样一条规则：

.pXSMma_body>*{ z-index:1; position:relative }

它让会话正文的每一个直接子元素都各自成为一个层叠上下文。于是渲染在 pane A 内部的 fixed 元素永远无法逃出 pane A，而 pane B（装着 .wSkVaW_widthHandle 的聊天 pane）整体绘制在 pane A 之上。对话框自己写多大的 z-index 都失去意义，只有各个 pane 的相对顺序在起作用。

建议的修法

• 方案 a：去掉 .pXSMma_body>* 上的 z-index:1（如需定位可保留 position:relative）。堆叠顺序由 DOM 顺序本来就能稳定保证。
• 方案 b：或者让「对话框类插槽」走 portal / 宿主自己的 overlay 层渲染（div.pI_x6G_overlayLayer 已经是这个角色），使插件不再继承 pane 的层叠限制。
• 方案 c（针对手柄本身，建议顺带做）：@media (hover: none){ [class*="widthHandle"]{ pointer-events: none } } —— 触屏上这个手柄本来就无从发现（没有 hover 提示、没有任何视觉），留着唯一可观测的效果就是吃掉点击；接了鼠标的平板（hover: hover）不受影响，官方拖拽照旧。

同一元素的第二个症状

.wSkVaW_widthHandle::after 是拖拽指示条（默认 opacity: 0，:hover / [data-dragging] 时为 1）。在 hover: none 设备上，触摸会留下 sticky hover，指示条被永久点亮，表现为一条来路不明的灰色竖条画在无关界面上。应当用指针能力查询把它关掉。

本地临时规避

本地一个纯 CSS 插件对 @media (hover: none) 施加了：

[class*="widthHandle"]::after { display: none !important; }
[class*="widthHandle"] { pointer-events: none !important; }

这能止住这一个手柄的症状，但结构性问题依旧存在 —— 任何在会话 pane 内渲染模态的插件都会中招。

[PerryLink]

你的 elementsFromPoint 实测已经证明了结构性问题本身（对话框与手柄不在同一层叠上下文），这个结论不依赖根因猜测。逐条核对我能核的部分：

1. 「方案 b」的 overlay 层真实存在：packages/client/ui-layout/src/client/AppFrame.tsx:230 —— { div className={css.overlayLayer} data-shell-overlay }。它就是给这类跨 pane 模态准备的宿主级覆盖层，走 portal 到它是正确方向。
2. 你推测的 .pXSMma_body>*{z-index:1;position:relative} 规则：我在 dsh-client-ui-conversation 的源码里没有搜到任何 z-index 声明（0 命中）—— 可能已被改掉、或在别的包/别的形态里。建议在 0.1.5-rc.2 上对这个 class 做一次 computed style 复核再下定论。
3. 「方案 c」对触屏手柄的处置（hover:none 下 pointer-events:none / 关掉 ::after 常亮）在纯触屏上零代价，值得顺带提。

（基于 0.1.5-rc.2 源码核对；未核实的部分已在文中标出。）

[chenshi723]

谢谢核对。第 2 条我在本地装好的 0.1.5-rc.2 上复核了，那条规则是真实存在的：

• dsh-client-ui-conversation 的打包产物（lib/client.js）里就有
  .pXSMma_body>*{z-index:1;position:relative}，
  以及 .pXSMma_body>.pXSMma_workspaceRow{z-index:10}。
• 也就是 position:relative + z-index:1 会给 body 的每个直接子元素各开一个层叠上下文，
  pane 内插件的模态即使 z-index 99999 也出不去 —— 这正好解释了 elementsFromPoint 的实测。
• 你当时 0 命中，可能是搜的是源码仓库里的源文件而不是打包产物。

另外第 1 条也确认了：ui-layout 里 div className={css.overlayLayer} data-shell-overlay
确实存在，CSS 是 z-index:20 + pointer-events:none（子元素 auto）；拖拽手柄 .pI_x6G_handle 是 z-index:11。
20 > 11，所以挂 overlay 确实能盖住手柄，方案 b 可行。