Fix settings panel sidebar resize handle #195

New issue

Closed

opened 2026-06-01 09:50:57 +00:00 by steve · 0 comments

steve commented

2026-06-01 09:50:57 +00:00

Owner

The settings panel shows a sidebar resize handle, but dragging it does not change
the settings navigation width.

Problem

The settings sidebar is rendered through the shared sidebar component and exposes
the rail/resize affordance. In the settings panel, pointer resizing appears to be
ignored, leaving the sidebar stuck at its default width.

Goal

Make the settings panel resize handle functional so users can adjust the
settings navigation width without breaking the content pane layout.

Scope

Trace the settings sidebar Sidebar.Provider, Sidebar.Root, and
Sidebar.Rail configuration.
Fix any missing width binding, CSS variable update, pointer event handling, or
overlay/pointer target issue that prevents settings sidebar resizing.
Add focused Playwright coverage that drags the settings resize handle and
asserts the sidebar width changes.
Document the settings sidebar resize behavior in the settings/workspace spec.

Non-goals

Redesign settings navigation.
Change the main workspace dock/sidebar resize behavior unless it shares the
exact bug.
Persist settings sidebar width unless an existing local sidebar contract
already provides that behavior.

Acceptance Criteria

The settings panel resize handle can be dragged with a pointer.
Dragging the handle changes the settings navigation/sidebar width by a visible
amount.
The settings content pane remains visible and usable after resizing.
The fix has E2E coverage in the workspace settings tests.

Implementation Notes

Prefer the existing shared sidebar resize API over a settings-only drag
implementation.
Check whether the settings provider uses a static --sidebar-width style that
prevents the shared component from updating width.
Keep min/max widths consistent with the shared sidebar component.

Suggested Files or Specs To Inspect

packages/workspace/src/lib/components/configuration/configuration.svelte
packages/ui/src/lib/components/sidebar-custom/
packages/workspace/e2e/core-plugin-settings.spec.ts
spec/src/30-cross-package-contracts/configuration-and-settings.md

Validation Commands

pnpm --filter @lapis-notes/workspace check:all
pnpm --filter @lapis-notes/workspace test:e2e -- e2e/core-plugin-settings.spec.ts --project chromium
pnpm test:smoke

Follow-up to #192 — Adopt Obsidian-style settings navigation

Follow-up Tasks

Implementation Summary

Fixed the settings sidebar resize handle by letting the settings provider own its initial width instead of overriding --sidebar-width, added settings-scoped 2px rail hover/focus styling, documented the settings-specific resize contract, and added Playwright coverage for dragging the handle and preserving the content pane.

The settings panel shows a sidebar resize handle, but dragging it does not change the settings navigation width. ## Problem The settings sidebar is rendered through the shared sidebar component and exposes the rail/resize affordance. In the settings panel, pointer resizing appears to be ignored, leaving the sidebar stuck at its default width. ## Goal Make the settings panel resize handle functional so users can adjust the settings navigation width without breaking the content pane layout. ## Scope - Trace the settings sidebar `Sidebar.Provider`, `Sidebar.Root`, and `Sidebar.Rail` configuration. - Fix any missing width binding, CSS variable update, pointer event handling, or overlay/pointer target issue that prevents settings sidebar resizing. - Add focused Playwright coverage that drags the settings resize handle and asserts the sidebar width changes. - Document the settings sidebar resize behavior in the settings/workspace spec. ## Non-goals - Redesign settings navigation. - Change the main workspace dock/sidebar resize behavior unless it shares the exact bug. - Persist settings sidebar width unless an existing local sidebar contract already provides that behavior. ## Acceptance Criteria - The settings panel resize handle can be dragged with a pointer. - Dragging the handle changes the settings navigation/sidebar width by a visible amount. - The settings content pane remains visible and usable after resizing. - The fix has E2E coverage in the workspace settings tests. ## Implementation Notes - Prefer the existing shared sidebar resize API over a settings-only drag implementation. - Check whether the settings provider uses a static `--sidebar-width` style that prevents the shared component from updating width. - Keep min/max widths consistent with the shared sidebar component. ## Suggested Files or Specs To Inspect - `packages/workspace/src/lib/components/configuration/configuration.svelte` - `packages/ui/src/lib/components/sidebar-custom/` - `packages/workspace/e2e/core-plugin-settings.spec.ts` - `spec/src/30-cross-package-contracts/configuration-and-settings.md` ## Validation Commands - `pnpm --filter @lapis-notes/workspace check:all` - `pnpm --filter @lapis-notes/workspace test:e2e -- e2e/core-plugin-settings.spec.ts --project chromium` - `pnpm test:smoke` ## Related Issues - Follow-up to #192 — [Adopt Obsidian-style settings navigation](../closed/192-adopt-obsidian-style-settings-navigation.md) ## Follow-up Tasks ## Implementation Summary Fixed the settings sidebar resize handle by letting the settings provider own its initial width instead of overriding --sidebar-width, added settings-scoped 2px rail hover/focus styling, documented the settings-specific resize contract, and added Playwright coverage for dragging the handle and preserving the content pane.

steve added the

labels

2026-06-01 09:50:57 +00:00

steve referenced this issue

2026-06-01 09:59:58 +00:00

Fix markdown list callout settings polish #196