🐧 Web-Linux — Bug & UI/UX Review
Branch reviewed: main
Review date: 2026-08-27
Scope: source code, desktop and window management, app registry, affected applications, and shared styles.
I went through the reported issues and reviewed the related source code. Where the code alone is not enough to verify the reported behavior, the item is marked Needs reproduction.
Summary
The reported findings fall into three main groups:
- Bug reports: missing favicon, desktop icon collisions, drag/drop interference, resize/scrollbar conflicts, dark-mode contrast, default window-size problems, dock overflow, and viewport overflow during resize.
- UI/UX improvements: App Launcher scrollbar/category behavior, Chat window size, and dock icon alignment.
- Needs reproduction: Calculator, the reported dark-mode menu text issue.
Several findings share the same implementation areas, especially WindowFrame, registry.ts, Desktop.tsx, Dock.tsx, and the shared theme/scrollbar styles.
This document is a single consolidated report; the items can be addressed individually or grouped by the maintainer as needed.
Findings
1. Missing favicon
Type: 🐛 Bug
Current behavior
The application has no favicon, so the browser tab shows the default/blank icon.
Expected behavior
The Web-Linux application should display its project favicon in the browser tab.
Source
Web_Based_Ubuntu_Linux/app/index.html does not define a <link rel="icon"> entry.
Suggested fix
Add a favicon asset under public/ and reference it from index.html:
<link rel="icon" type="image/svg+xml" href="/favicon.svg" />
Suggested Issue title
fix: add favicon to the Web-Linux application
2. Desktop icons can overlap and desktop file-drop handling interferes with icon dragging
Type: 🐛 Bug / 🎨 UX
Verification: Collision/drop-zone logic is visible in the source; drag difficulty should be reproduced
This finding contains three related but independently fixable problems.
2.1 Icons can be placed on top of each other
Current behavior: multiple desktop icons can be moved to the same position.
Expected behavior: one desktop grid cell should not contain multiple icons. A dragged icon should move to a free cell or displace according to a defined desktop policy.
Source: src/components/Desktop.tsx and src/hooks/useOSStore.tsx.
The desktop snaps positions to a grid, but UPDATE_DESKTOP_ICON_POSITION does not check whether another icon already occupies the target cell.
Suggested fix: treat the snapped position as a logical grid cell and check occupancy before storing it. If the target is occupied, choose the nearest free cell or keep the original position.
2.2 Icon dragging can trigger text selection and feels difficult to control
Current behavior: dragging an icon can select its text or feel inconsistent instead of behaving like a single drag gesture.
Expected behavior: pressing and dragging an icon should move it smoothly without selecting text.
Source: src/components/Desktop.tsx (handleIconMouseDown, handleMouseMove, handleMouseUp).
Suggested fix: use Pointer Events with pointer capture, keep the original pointer offset for the whole drag session, and explicitly disable text/image dragging on desktop icons.
2.3 The desktop upload drop-zone reacts to unrelated drags
Current behavior: while moving a desktop icon, the large file-upload state can appear (Drop files here...).
Expected behavior: the file-upload overlay should activate only when the dragged data actually contains files.
Source: src/components/Desktop.tsx attaches drag-over/drop handlers to the whole desktop.
Suggested fix: check e.dataTransfer.types for Files before activating the upload state or calling preventDefault().
Suggested Issue titles
fix(desktop): prevent desktop icon collisions when dragging iconsfix(desktop): improve icon dragging and prevent text selectionfix(desktop): activate file-drop overlay only for file drags
These can be addressed individually within this report or grouped together where the same underlying component is involved.
3. App Launcher category row and scrollbar styling need improvement
Type: 🎨 UI/UX improvement
Current behavior
The launcher shows these categories in one row:
Favorites · All · System · Productivity · Internet · Media · Games · DevTools · Creative
The app list is vertically scrollable, but the scrollbar uses the browser's default appearance instead of the project's custom scrollbar styling.
Expected behavior
The category row should have intentional responsive overflow behavior, and the application list should use the same scrollbar style as the rest of the interface.
Source
src/components/AppLauncher.tsx and src/index.css.
The launcher uses overflow-y-auto, while the project already defines .custom-scrollbar.
Suggested fix
Apply the shared scrollbar class to the app list and define a deliberate behavior for the category row on narrow widths rather than leaving the browser's default overflow behavior.
Suggested Issue title
improve(app-launcher): refine category overflow and scrollbar styling
4. Calculator appears non-functional
Type: 🐛 Bug
Verification: Needs reproduction
Current behavior
The Calculator reportedly does not work.
Expected behavior
Basic operations such as 2 + 3 = 5 should work, along with the normal calculator controls.
Source
src/apps/Calculator.tsx and src/apps/registry.ts.
Static inspection shows calculator state and evaluation logic, so the source alone does not establish why the application fails at runtime.
Suggested reproduction
1. Open Calculator.
2. Enter 2.
3. Press +.
4. Enter 3.
5. Press =.
6. Record the result or error.
Also test mouse and keyboard input separately.
Suggested Issue title
bug(calculator): calculator input or evaluation is not functioning
5. Window resize handle interferes with inner scrollbars
Type: 🐛 Bug
Verification: Reproduce at runtime before opening the Issue.
Current behavior
In apps such as System Monitor and Clock, the outer window resize interaction can activate when the pointer is over the inner scrollbar instead of letting the user scroll the app content.
Expected behavior
The inner scrollbar should remain usable. Window resizing should begin only when the pointer is actually on the window frame edge.
Source
src/components/WindowFrame.tsxsrc/apps/SystemMonitor.tsxsrc/apps/Clock.tsx
WindowFrame creates edge resize handles, while these apps contain scrollable regions near the edge.
Suggested fix
Reduce or reposition the resize hit area so it does not cover content controls. Pointer capture can be used after a resize starts, but the resize gesture should not begin from an inner scrollbar.
Suggested Issue title
fix(window): prevent resize handles from intercepting inner scrollbars
6. GitHub quick-link icon is unreadable in dark mode
Type: 🐛 Bug
Current behavior
The GitHub quick-link icon is visible in light mode but becomes too dark to see in dark mode.
Expected behavior
The GitHub icon should maintain sufficient contrast in both themes.
Source
src/apps/Browser.tsx defines the GitHub quick-link with a hard-coded dark color (#333).
Suggested fix
Use a theme-aware color, currentColor, or another variant with sufficient contrast. The same review should be applied to other quick-link icons for consistency.
Suggested Issue title
fix(browser): improve GitHub quick-link contrast in dark mode
7. Chat opens with a window that is too small for its conversation list
Type: 🎨 UI/UX improvement
Verification: Visual reproduction recommended
Current behavior
The Chat window opens relatively small, so conversation rows can feel cramped or have their content clipped.
Expected behavior
The default size should show the conversation list and main content comfortably without immediate manual resizing.
Source
src/apps/registry.ts defines Chat as 480 × 600, while src/apps/Chat.tsx uses a fixed-width conversation sidebar.
Suggested fix
Increase the default width and make the conversation sidebar more responsive. The exact target size should follow the available viewport and the actual content requirements.
Suggested Issue title
improve(chat): increase default window size for conversation layout
8. Music Player default height hides playback controls
Type: 🐛 Bug
Verification: The source supports the reported sizing problem.
Current behavior
The Music Player can open with the bottom playback controls clipped or outside the visible area. The controls become visible after manually increasing the window height.
Expected behavior
The default window size should display the primary player controls without requiring the user to resize it first.
Source
src/apps/registry.ts — default size 520 × 440src/apps/MusicPlayer.tsx — vertically stacked player content
Suggested fix
Increase the default height or redesign the content layout so the primary controls fit within the default window.
Suggested Issue title
fix(music-player): prevent playback controls from being clipped at default size
9. Tic-Tac-Toe default height clips lower controls
Type: 🐛 Bug
Verification: The source supports the reported sizing problem.
Current behavior
The game opens with some lower controls not fully visible until the window is manually enlarged.
Expected behavior
The board, score, and controls should be visible at first open.
Source
src/apps/registry.ts — default size 400 × 440src/apps/TicTacToe.tsx
Suggested fix
Increase the default height and/or define a content-aware minimum height for the game.
Suggested Issue title
fix(tic-tac-toe): prevent controls from being clipped at default size
10. 2048 default height clips game content
Type: 🐛 Bug
Verification: The source supports the reported sizing problem.
Current behavior
The game opens too short, so some controls/content are not visible until the window is enlarged.
Expected behavior
The board, score, and controls should be visible at first open.
Source
src/apps/registry.ts — default size 400 × 480src/apps/Game2048.tsx
Suggested fix
Increase the default height or calculate the minimum content height from the board and controls. A responsive board can further improve smaller screens.
Suggested Issue title
fix(2048): prevent game content from being clipped at default size
11. Dark-mode menu text remains black in Code Editor, JSON Formatter, and Markdown Preview
Type: 🐛 Theme bug
Verification: Needs reproduction for the exact controls
Current behavior
The reported menu/control text remains black in dark mode in:
- Code Editor
- JSON Formatter
- Markdown Preview
Expected behavior
All interactive text and menus should remain readable in both light and dark themes.
Source
Relevant files:
src/apps/CodeEditor.tsxsrc/apps/JsonFormatter.tsxsrc/apps/MarkdownPreview.tsxsrc/index.css
The apps use theme variables in many places, but the exact black-text element reported is not unambiguous from static inspection. Native controls such as <select>/<option> should also be checked because browser rendering can bypass normal theme expectations.
Suggested fix
Audit menu/select/popover styles for hard-coded colors, inherited colors, and color-scheme. Prefer the shared theme tokens and provide explicit dark-mode styling where native controls need it.
Suggested Issue title
fix(theme): correct dark-mode text contrast in developer app menus
12. Bottom dock overflows when many applications are open
Type: 🐛 Bug / 🎨 UX
Current behavior
Every opened unpinned application is added to the dock. As more applications open, the dock keeps growing horizontally until it overflows the usable screen width.
Expected behavior
The dock should remain within the viewport and provide an intentional way to access additional open applications.
Source
src/components/Dock.tsx renders the open application list directly and does not define a compact overflow/collapse mechanism.
Suggested fix
Prefer an overflow button/menu after the available width is reached. A bounded horizontal scroll area is another option, but a compact overflow control is more consistent with a desktop dock.
Suggested Issue title
fix(dock): prevent overflow when many applications are open
13. Dock icons are not visually aligned
Type: 🎨 UI/UX improvement
Verification: Visual confirmation recommended
Current behavior
Some application icons appear slightly higher or lower than others even though their buttons share the same size.
Expected behavior
Icons should appear visually centered and aligned across the dock.
Source
src/components/Dock.tsx uses fixed-size buttons and Lucide icons, but different glyph shapes can have different optical centers.
Suggested fix
Keep the existing fixed button size and center alignment, normalize icon size (for example 22–24px), and review any icons that need optical rather than mathematical centering.
Suggested Issue title
improve(dock): normalize visual alignment of application icons
14. Resizable windows can exceed the viewport width
Type: 🐛 Bug
Current behavior
A window can be resized wider than the available browser viewport, causing horizontal overflow.
Expected behavior
A resizable window should never extend beyond the usable viewport unless the project intentionally supports off-screen windows.
Source
src/components/WindowFrame.tsx clamps the minimum width but does not clamp the maximum width during east/west resizing. src/hooks/useOSStore.tsx stores the supplied geometry without a final viewport clamp.
The resize logic currently allows patterns such as:
nw = Math.max(MIN_W, origW + dx)
without an upper bound based on the viewport.
Suggested fix
Calculate the available width from the current window position and viewport, then clamp the requested size. Apply the same constraint when moving/restoring windows and when the browser viewport becomes smaller.
Suggested Issue title
fix(window): prevent resizable windows from exceeding the viewport
Shared improvements
These are not necessarily separate Issues. They are good implementation directions for maintainers.
1. Centralize window constraints
Window geometry is handled across the window frame, store, and app registry. A shared clampWindowToViewport() helper would keep move, resize, restore, and browser-resize behavior consistent.
2. Add content-aware window minimum sizes
The registry already has defaultSize and minSize. A contentMinimumSize (or equivalent) could prevent apps from opening below the size required by their UI.
This could reduce several reports involving:
- Music Player
- Tic-Tac-Toe
- 2048
- Chat
- Clock
- System Monitor
3. Standardize scrollbars
The project already provides .custom-scrollbar. Scrollable areas should consistently use the shared style instead of falling back to the browser default.
4. Use theme tokens consistently
Shared variables such as --text-primary, --text-secondary, --bg-input, and related tokens should be preferred over hard-coded colors for UI that must work in both themes.
5. Separate desktop icon drag from host-file drop
Desktop icon dragging and external file upload are different interactions. They should have separate activation conditions so one cannot accidentally trigger the other.
Final classification
| # |
Finding |
Classification |
| 1 |
Missing favicon |
🐛 Bug |
| 2 |
Desktop icon drag/collision/drop-zone |
🐛 Bug / 🎨 UX |
| 3 |
App Launcher categories/scrollbar |
🎨 UI/UX |
| 4 |
Calculator |
🐛 Bug — Needs reproduction |
| 5 |
Resize handle vs. inner scrollbar |
🐛 Bug |
| 6 |
GitHub icon in dark mode |
🐛 Bug |
| 7 |
Chat default size |
🎨 UI/UX |
| 8 |
Music Player default height |
🐛 Bug |
| 9 |
Tic-Tac-Toe default height |
🐛 Bug |
| 10 |
2048 default height |
🐛 Bug |
| 11 |
Developer-app dark-mode text |
🐛 Bug/theme — Needs reproduction |
| 12 |
Dock overflow |
🐛 Bug / 🎨 UX |
| 13 |
Dock icon alignment |
🎨 UI/UX |
| 14 |
Window exceeds viewport |
🐛 Bug |
🐧 Web-Linux — Bug & UI/UX Review
Branch reviewed:
mainReview date: 2026-08-27
Scope: source code, desktop and window management, app registry, affected applications, and shared styles.
Summary
The reported findings fall into three main groups:
Several findings share the same implementation areas, especially
WindowFrame,registry.ts,Desktop.tsx,Dock.tsx, and the shared theme/scrollbar styles.This document is a single consolidated report; the items can be addressed individually or grouped by the maintainer as needed.
Findings
1. Missing favicon
Type: 🐛 Bug
Current behavior
The application has no favicon, so the browser tab shows the default/blank icon.
Expected behavior
The Web-Linux application should display its project favicon in the browser tab.
Source
Web_Based_Ubuntu_Linux/app/index.htmldoes not define a<link rel="icon">entry.Suggested fix
Add a favicon asset under
public/and reference it fromindex.html:Suggested Issue title
fix: add favicon to the Web-Linux application2. Desktop icons can overlap and desktop file-drop handling interferes with icon dragging
Type: 🐛 Bug / 🎨 UX
Verification: Collision/drop-zone logic is visible in the source; drag difficulty should be reproduced
This finding contains three related but independently fixable problems.
2.1 Icons can be placed on top of each other
Current behavior: multiple desktop icons can be moved to the same position.
Expected behavior: one desktop grid cell should not contain multiple icons. A dragged icon should move to a free cell or displace according to a defined desktop policy.
Source:
src/components/Desktop.tsxandsrc/hooks/useOSStore.tsx.The desktop snaps positions to a grid, but
UPDATE_DESKTOP_ICON_POSITIONdoes not check whether another icon already occupies the target cell.Suggested fix: treat the snapped position as a logical grid cell and check occupancy before storing it. If the target is occupied, choose the nearest free cell or keep the original position.
2.2 Icon dragging can trigger text selection and feels difficult to control
Current behavior: dragging an icon can select its text or feel inconsistent instead of behaving like a single drag gesture.
Expected behavior: pressing and dragging an icon should move it smoothly without selecting text.
Source:
src/components/Desktop.tsx(handleIconMouseDown,handleMouseMove,handleMouseUp).Suggested fix: use Pointer Events with pointer capture, keep the original pointer offset for the whole drag session, and explicitly disable text/image dragging on desktop icons.
2.3 The desktop upload drop-zone reacts to unrelated drags
Current behavior: while moving a desktop icon, the large file-upload state can appear (
Drop files here...).Expected behavior: the file-upload overlay should activate only when the dragged data actually contains files.
Source:
src/components/Desktop.tsxattaches drag-over/drop handlers to the whole desktop.Suggested fix: check
e.dataTransfer.typesforFilesbefore activating the upload state or callingpreventDefault().Suggested Issue titles
fix(desktop): prevent desktop icon collisions when dragging iconsfix(desktop): improve icon dragging and prevent text selectionfix(desktop): activate file-drop overlay only for file dragsThese can be addressed individually within this report or grouped together where the same underlying component is involved.
3. App Launcher category row and scrollbar styling need improvement
Type: 🎨 UI/UX improvement
Current behavior
The launcher shows these categories in one row:
Favorites · All · System · Productivity · Internet · Media · Games · DevTools · CreativeThe app list is vertically scrollable, but the scrollbar uses the browser's default appearance instead of the project's custom scrollbar styling.
Expected behavior
The category row should have intentional responsive overflow behavior, and the application list should use the same scrollbar style as the rest of the interface.
Source
src/components/AppLauncher.tsxandsrc/index.css.The launcher uses
overflow-y-auto, while the project already defines.custom-scrollbar.Suggested fix
Apply the shared scrollbar class to the app list and define a deliberate behavior for the category row on narrow widths rather than leaving the browser's default overflow behavior.
Suggested Issue title
improve(app-launcher): refine category overflow and scrollbar styling4. Calculator appears non-functional
Type: 🐛 Bug
Verification: Needs reproduction
Current behavior
The Calculator reportedly does not work.
Expected behavior
Basic operations such as
2 + 3 = 5should work, along with the normal calculator controls.Source
src/apps/Calculator.tsxandsrc/apps/registry.ts.Static inspection shows calculator state and evaluation logic, so the source alone does not establish why the application fails at runtime.
Suggested reproduction
Also test mouse and keyboard input separately.
Suggested Issue title
bug(calculator): calculator input or evaluation is not functioning5. Window resize handle interferes with inner scrollbars
Type: 🐛 Bug
Verification: Reproduce at runtime before opening the Issue.
Current behavior
In apps such as System Monitor and Clock, the outer window resize interaction can activate when the pointer is over the inner scrollbar instead of letting the user scroll the app content.
Expected behavior
The inner scrollbar should remain usable. Window resizing should begin only when the pointer is actually on the window frame edge.
Source
src/components/WindowFrame.tsxsrc/apps/SystemMonitor.tsxsrc/apps/Clock.tsxWindowFramecreates edge resize handles, while these apps contain scrollable regions near the edge.Suggested fix
Reduce or reposition the resize hit area so it does not cover content controls. Pointer capture can be used after a resize starts, but the resize gesture should not begin from an inner scrollbar.
Suggested Issue title
fix(window): prevent resize handles from intercepting inner scrollbars6. GitHub quick-link icon is unreadable in dark mode
Type: 🐛 Bug
Current behavior
The GitHub quick-link icon is visible in light mode but becomes too dark to see in dark mode.
Expected behavior
The GitHub icon should maintain sufficient contrast in both themes.
Source
src/apps/Browser.tsxdefines the GitHub quick-link with a hard-coded dark color (#333).Suggested fix
Use a theme-aware color,
currentColor, or another variant with sufficient contrast. The same review should be applied to other quick-link icons for consistency.Suggested Issue title
fix(browser): improve GitHub quick-link contrast in dark mode7. Chat opens with a window that is too small for its conversation list
Type: 🎨 UI/UX improvement
Verification: Visual reproduction recommended
Current behavior
The Chat window opens relatively small, so conversation rows can feel cramped or have their content clipped.
Expected behavior
The default size should show the conversation list and main content comfortably without immediate manual resizing.
Source
src/apps/registry.tsdefines Chat as480 × 600, whilesrc/apps/Chat.tsxuses a fixed-width conversation sidebar.Suggested fix
Increase the default width and make the conversation sidebar more responsive. The exact target size should follow the available viewport and the actual content requirements.
Suggested Issue title
improve(chat): increase default window size for conversation layout8. Music Player default height hides playback controls
Type: 🐛 Bug
Verification: The source supports the reported sizing problem.
Current behavior
The Music Player can open with the bottom playback controls clipped or outside the visible area. The controls become visible after manually increasing the window height.
Expected behavior
The default window size should display the primary player controls without requiring the user to resize it first.
Source
src/apps/registry.ts— default size520 × 440src/apps/MusicPlayer.tsx— vertically stacked player contentSuggested fix
Increase the default height or redesign the content layout so the primary controls fit within the default window.
Suggested Issue title
fix(music-player): prevent playback controls from being clipped at default size9. Tic-Tac-Toe default height clips lower controls
Type: 🐛 Bug
Verification: The source supports the reported sizing problem.
Current behavior
The game opens with some lower controls not fully visible until the window is manually enlarged.
Expected behavior
The board, score, and controls should be visible at first open.
Source
src/apps/registry.ts— default size400 × 440src/apps/TicTacToe.tsxSuggested fix
Increase the default height and/or define a content-aware minimum height for the game.
Suggested Issue title
fix(tic-tac-toe): prevent controls from being clipped at default size10. 2048 default height clips game content
Type: 🐛 Bug
Verification: The source supports the reported sizing problem.
Current behavior
The game opens too short, so some controls/content are not visible until the window is enlarged.
Expected behavior
The board, score, and controls should be visible at first open.
Source
src/apps/registry.ts— default size400 × 480src/apps/Game2048.tsxSuggested fix
Increase the default height or calculate the minimum content height from the board and controls. A responsive board can further improve smaller screens.
Suggested Issue title
fix(2048): prevent game content from being clipped at default size11. Dark-mode menu text remains black in Code Editor, JSON Formatter, and Markdown Preview
Type: 🐛 Theme bug
Verification: Needs reproduction for the exact controls
Current behavior
The reported menu/control text remains black in dark mode in:
Expected behavior
All interactive text and menus should remain readable in both light and dark themes.
Source
Relevant files:
src/apps/CodeEditor.tsxsrc/apps/JsonFormatter.tsxsrc/apps/MarkdownPreview.tsxsrc/index.cssThe apps use theme variables in many places, but the exact black-text element reported is not unambiguous from static inspection. Native controls such as
<select>/<option>should also be checked because browser rendering can bypass normal theme expectations.Suggested fix
Audit menu/select/popover styles for hard-coded colors, inherited colors, and
color-scheme. Prefer the shared theme tokens and provide explicit dark-mode styling where native controls need it.Suggested Issue title
fix(theme): correct dark-mode text contrast in developer app menus12. Bottom dock overflows when many applications are open
Type: 🐛 Bug / 🎨 UX
Current behavior
Every opened unpinned application is added to the dock. As more applications open, the dock keeps growing horizontally until it overflows the usable screen width.
Expected behavior
The dock should remain within the viewport and provide an intentional way to access additional open applications.
Source
src/components/Dock.tsxrenders the open application list directly and does not define a compact overflow/collapse mechanism.Suggested fix
Prefer an overflow button/menu after the available width is reached. A bounded horizontal scroll area is another option, but a compact overflow control is more consistent with a desktop dock.
Suggested Issue title
fix(dock): prevent overflow when many applications are open13. Dock icons are not visually aligned
Type: 🎨 UI/UX improvement
Verification: Visual confirmation recommended
Current behavior
Some application icons appear slightly higher or lower than others even though their buttons share the same size.
Expected behavior
Icons should appear visually centered and aligned across the dock.
Source
src/components/Dock.tsxuses fixed-size buttons and Lucide icons, but different glyph shapes can have different optical centers.Suggested fix
Keep the existing fixed button size and center alignment, normalize icon size (for example 22–24px), and review any icons that need optical rather than mathematical centering.
Suggested Issue title
improve(dock): normalize visual alignment of application icons14. Resizable windows can exceed the viewport width
Type: 🐛 Bug
Current behavior
A window can be resized wider than the available browser viewport, causing horizontal overflow.
Expected behavior
A resizable window should never extend beyond the usable viewport unless the project intentionally supports off-screen windows.
Source
src/components/WindowFrame.tsxclamps the minimum width but does not clamp the maximum width during east/west resizing.src/hooks/useOSStore.tsxstores the supplied geometry without a final viewport clamp.The resize logic currently allows patterns such as:
without an upper bound based on the viewport.
Suggested fix
Calculate the available width from the current window position and viewport, then clamp the requested size. Apply the same constraint when moving/restoring windows and when the browser viewport becomes smaller.
Suggested Issue title
fix(window): prevent resizable windows from exceeding the viewportShared improvements
These are not necessarily separate Issues. They are good implementation directions for maintainers.
1. Centralize window constraints
Window geometry is handled across the window frame, store, and app registry. A shared
clampWindowToViewport()helper would keep move, resize, restore, and browser-resize behavior consistent.2. Add content-aware window minimum sizes
The registry already has
defaultSizeandminSize. AcontentMinimumSize(or equivalent) could prevent apps from opening below the size required by their UI.This could reduce several reports involving:
3. Standardize scrollbars
The project already provides
.custom-scrollbar. Scrollable areas should consistently use the shared style instead of falling back to the browser default.4. Use theme tokens consistently
Shared variables such as
--text-primary,--text-secondary,--bg-input, and related tokens should be preferred over hard-coded colors for UI that must work in both themes.5. Separate desktop icon drag from host-file drop
Desktop icon dragging and external file upload are different interactions. They should have separate activation conditions so one cannot accidentally trigger the other.
Final classification