Body
Environment
- OS: Windows 11
- VS Code version: latest stable
- Extension:
subframe7536.custom-ui-style (v0.6.9)
- Theme used with: Islands Dark (
bwya77.islands-dark)
- Other relevant extensions: GitHub Copilot Chat
Bug 1 — Copilot Chat toolbar disappears on multi-line input
Steps to reproduce:
- Open the GitHub Copilot Chat panel in the auxiliary sidebar (right side).
- Click the chat input field.
- Type enough text to cause the textarea to expand to 4+ lines (or paste a multi-line message).
- Observe the toolbar row below the textarea.
Expected behavior:
The toolbar row (containing +, Agent, model selector, send button) remains visible below the textarea at all times, regardless of how many lines are typed.
Actual behavior:
The toolbar row is completely hidden — clipped off by the panel boundary. The more lines typed, the more the toolbar is pushed out of view. The panel edge cuts off exactly where the toolbar row should appear.
Root cause (traced manually):
The stylesheet injected by Custom UI Style includes two rules that interact destructively on Windows:
".part.auxiliarybar .split-view-view": {
"max-height": "calc(100% - 24px) !important"
},
".interactive-input-part": {
"overflow": "hidden !important"
}
The parent .part.auxiliarybar already enforces its own overflow: hidden and max-height. Adding a second max-height constraint on .split-view-view creates a fixed ceiling inside the panel. When the Copilot textarea grows, VS Code's internal layout engine tries to push the toolbar row downward, but the row exits the clipping boundary set by these stacked constraints and becomes invisible.
Fix that worked:
Remove the max-height from .part.auxiliarybar .split-view-view (the parent already handles the constraint), and remove overflow: hidden from .interactive-input-part (the border-radius itself clips the visual corners without needing overflow clipping):
".part.auxiliarybar .split-view-view": {
// max-height removed
},
".interactive-input-part": {
"border-radius": "var(--islands-widget-radius) !important"
// overflow: hidden removed
}
After applying this fix and running Custom UI Style: Reload, the toolbar remains visible even with very long multi-line input.
Bug 2 — Related: .part.editor overflow:hidden clips webview-based extension content (informational)
This is a separate but related observation on Windows.
The stylesheet sets:
".part.editor": {
"overflow": "hidden !important",
"border-radius": "var(--islands-panel-radius) !important"
}
The overflow: hidden + border-radius combination physically clips the edges of any webview rendered inside the editor panel (e.g., Office Viewer's Markdown preview). Since webviews are isolated HTML documents, their internal content can be cut off by the outer VS Code shell's overflow clipping — this is not fixable from inside the webview itself.
In my case, combined with a third-party extension's CSS that zeroed out bottom padding inside the webview (padding: 0 5%), the last line of Markdown content was always visually clipped at the bottom of the panel even after scrolling to the end.
This may be acceptable by design (the rounded panel requires overflow: hidden to clip the corners). Mentioning it here in case it's worth adding a note to the documentation for users who encounter similar webview rendering issues on Windows.
Additional notes
- Both issues were reproducible consistently on Windows 11 after installing the extension with the Islands Dark theme stylesheet.
- Behavior on macOS is unknown — may not reproduce due to differences in VS Code's webview compositing.
- The Copilot toolbar fix (Bug 1) is a direct stylesheet correction with no visual side effects observed.
Hope this helps — the extension is excellent overall and this was the only functional issue I encountered on Windows. Happy to provide more details if needed.
Body
Environment
subframe7536.custom-ui-style(v0.6.9)bwya77.islands-dark)Bug 1 — Copilot Chat toolbar disappears on multi-line input
Steps to reproduce:
Expected behavior:
The toolbar row (containing
+,Agent, model selector, send button) remains visible below the textarea at all times, regardless of how many lines are typed.Actual behavior:
The toolbar row is completely hidden — clipped off by the panel boundary. The more lines typed, the more the toolbar is pushed out of view. The panel edge cuts off exactly where the toolbar row should appear.
Root cause (traced manually):
The stylesheet injected by Custom UI Style includes two rules that interact destructively on Windows:
The parent
.part.auxiliarybaralready enforces its ownoverflow: hiddenandmax-height. Adding a secondmax-heightconstraint on.split-view-viewcreates a fixed ceiling inside the panel. When the Copilot textarea grows, VS Code's internal layout engine tries to push the toolbar row downward, but the row exits the clipping boundary set by these stacked constraints and becomes invisible.Fix that worked:
Remove the
max-heightfrom.part.auxiliarybar .split-view-view(the parent already handles the constraint), and removeoverflow: hiddenfrom.interactive-input-part(the border-radius itself clips the visual corners without needing overflow clipping):After applying this fix and running
Custom UI Style: Reload, the toolbar remains visible even with very long multi-line input.Bug 2 — Related:
.part.editoroverflow:hidden clips webview-based extension content (informational)This is a separate but related observation on Windows.
The stylesheet sets:
The
overflow: hidden+border-radiuscombination physically clips the edges of any webview rendered inside the editor panel (e.g., Office Viewer's Markdown preview). Since webviews are isolated HTML documents, their internal content can be cut off by the outer VS Code shell's overflow clipping — this is not fixable from inside the webview itself.In my case, combined with a third-party extension's CSS that zeroed out bottom padding inside the webview (
padding: 0 5%), the last line of Markdown content was always visually clipped at the bottom of the panel even after scrolling to the end.This may be acceptable by design (the rounded panel requires
overflow: hiddento clip the corners). Mentioning it here in case it's worth adding a note to the documentation for users who encounter similar webview rendering issues on Windows.Additional notes
Hope this helps — the extension is excellent overall and this was the only functional issue I encountered on Windows. Happy to provide more details if needed.