# Feature Specification: Browser Controls UI **Feature Branch**: `002-browser-controls-ui` **Created**: 2025-09-09 **Status**: Draft **Input**: User description: "Browser Controls UI, I want to add button and keyboard controls to the web browser, for now ctrl + to zoom, Ctrl - to unzoom, back/next mouse buttons, and ctrl shift c to copy url into wlcopy" ## Execution Flow (main) ``` 1. Parse user description from Input → Feature: Browser navigation and zoom controls with clipboard integration 2. Extract key concepts from description → Actors: Browser users → Actions: Zoom in/out, navigate back/forward, copy URL → Data: Current page URL, zoom level → Constraints: Linux clipboard integration (wlcopy) 3. For each unclear aspect: → Zoom levels follow Firefox behavior (30%-500%, per-domain persistence) → Navigation history edge cases handle empty history silently 4. Fill User Scenarios & Testing section → User can zoom and navigate using keyboard and mouse 5. Generate Functional Requirements → Each requirement focuses on user capabilities 6. Identify Key Entities → Browser state (zoom, history, current URL) 7. Run Review Checklist → All requirements clarified and specified 8. Return: SUCCESS (spec ready for planning) ``` --- ## ⚡ Quick Guidelines - ✅ Focus on WHAT users need and WHY - ❌ Avoid HOW to implement (no tech stack, APIs, code structure) - 👥 Written for business stakeholders, not developers --- ## User Scenarios & Testing *(mandatory)* ### Primary User Story A user browsing web content wants to quickly navigate and adjust their viewing experience using familiar keyboard shortcuts and mouse controls. They need to zoom in to read small text, zoom out to see more content, navigate through their browsing history, and easily share the current page URL with others. ### Acceptance Scenarios 1. **Given** the browser is displaying a webpage, **When** the user presses Ctrl+Plus, **Then** the page zooms in and content becomes larger 2. **Given** the browser is displaying a webpage, **When** the user presses Ctrl+Minus, **Then** the page zooms out and more content becomes visible 3. **Given** the user has navigated to previous pages, **When** the user clicks the back mouse button, **Then** the browser navigates to the previous page in history 4. **Given** the user has navigated back in history, **When** the user clicks the forward mouse button, **Then** the browser navigates to the next page in history 5. **Given** the browser is displaying a webpage, **When** the user presses Ctrl+Shift+C, **Then** the current page URL is copied to the system clipboard via wlcopy ### Edge Cases - What happens when user tries to zoom beyond 30% or 500% limits? (System ignores further zoom attempts) - How does system handle zoom keyboard shortcuts when no page is loaded? (System applies zoom to next loaded page) - What happens when back/forward mouse buttons are pressed but no history exists? (System does nothing/ignores silently) - How does system handle clipboard copy when wlcopy command is not available? (System tries fallback: xclip → xsel) ## Requirements *(mandatory)* ### Functional Requirements - **FR-001**: System MUST respond to Ctrl+Plus keyboard shortcut to zoom in the current webpage - **FR-002**: System MUST respond to Ctrl+Minus keyboard shortcut to zoom out the current webpage - **FR-003**: System MUST respond to back mouse button clicks to navigate to previous page in browsing history - **FR-004**: System MUST respond to forward mouse button clicks to navigate to next page in browsing history - **FR-005**: System MUST respond to Ctrl+Shift+C keyboard shortcut to copy current page URL to system clipboard - **FR-006**: System MUST integrate with wlcopy command for clipboard operations on Linux systems - **FR-007**: System MUST provide visual feedback when zoom level changes - **FR-008**: System MUST implement Firefox-style zoom levels (30%, 50%, 67%, 80%, 90%, 100%, 110%, 120%, 133%, 150%, 170%, 200%, 240%, 300%, 400%, 500%) - **FR-009**: System MUST persist zoom levels per-domain between browser sessions - **FR-011**: System MUST attempt clipboard fallback sequence (wlcopy → xclip → xsel) when primary clipboard tool fails - **FR-010**: System MUST handle cases where navigation history is empty (disable/ignore navigation attempts) - **FR-012**: System MUST update window title dynamically when page title changes (format: "Dumber - [Page Title]") ### Key Entities *(include if feature involves data)* - **Browser State**: Represents current browsing context including zoom level, navigation history, and active URL - **Navigation History**: Collection of previously visited pages enabling back/forward functionality - **Zoom Level**: Current magnification setting for webpage display --- ## Review & Acceptance Checklist *GATE: Automated checks run during main() execution* ### Content Quality - [x] No implementation details (languages, frameworks, APIs) - [x] Focused on user value and business needs - [x] Written for non-technical stakeholders - [x] All mandatory sections completed ### Requirement Completeness - [x] No [NEEDS CLARIFICATION] markers remain - [x] Requirements are testable and unambiguous - [x] Success criteria are measurable - [x] Scope is clearly bounded - [x] Dependencies and assumptions identified --- ## Execution Status *Updated by main() during processing* - [x] User description parsed - [x] Key concepts extracted - [x] Ambiguities marked - [x] User scenarios defined - [x] Requirements generated - [x] Entities identified - [x] Review checklist passed --- ## Implementation Notes ### Frontend Integration Requirements - The frontend needs to call `UpdatePageTitle` when the page loads to trigger the title update. This can be done via JavaScript when the page finishes loading. - Window title format: "Dumber - [Page Title]" (e.g., "Dumber - Google", "Dumber - Wikipedia") ---