Conversation
Member
abose
commented
Apr 22, 2026
abose
commented
User feedback indicated the old position (top-right of the sidebar nav) was better than the relocated positions inside the central control bar and the sidebar project-files-header. Restore the four divs in #mainNavBarRight with their original sprite-icon classes, drop the CCB .ccb-group-nav block and the sidebar-hover #show-in-file-tree button, and prune the CSS overrides that were added to host the buttons in the CCB. NavigationProvider wiring is unchanged — it still attaches to these IDs. Tests: - Move #showInfileTree and #searchNav click-dispatch tests to the NavigationAndHistory integ suite. - Add a scroll-to-selected test in SidebarTabs-integ-test for handleShowInTree's post-showInTree ViewUtils.scrollElementIntoView (previously uncovered). - Drop the obsolete CCB-side button tests.
Toggling the sidebar off/on with a large AI chat history (>1k messages, >10k DOM nodes) causes ~750ms of synchronous reflow on show, because `display: none` drops the layout object and Chromium rebuilds it from scratch. Adding `content-visibility: auto` lets the browser skip layout and paint for messages that are far off-screen; `contain-intrinsic-size` supplies a height estimate so scroll geometry stays stable. Measured on a 1098-message session: show-freeze dropped from ~752ms to ~89ms (~8.5x). Progressive enhancement — browsers without support just ignore the property.
…stant
The CCB sidebar-toggle routed through `$sidebar.hide()` → `display:none`,
which Chromium handles by destroying the element's layout tree. On
re-show, the browser has to rebuild layout + paint for the entire
sidebar subtree — for the AI chat panel with a large history
(>1k messages) that was ~750ms of synchronous work per toggle, and
scrollTop on the messages container was zeroed along the way.
Add an opt-in visibility-based hide mode to Resizer: when an element
has the `layout-preserve-hide` class, Resizer toggles a `layout-hidden`
class (which applies `visibility: hidden; pointer-events: none`) instead
of calling `$element.hide()` / `$element.show()`. The element's layout
object stays alive across the toggle, so descendants keep their scroll
positions and `content-visibility` caches, and re-show has no layout
rebuild to do.
`Resizer.isVisible` and the drag-path `:visible` checks were updated to
consult the new class so toggle() / drag-to-reopen still work correctly.
Four callers that read `$sidebar.is(":visible")` were switched to
`SidebarView.isVisible()` (which delegates to the updated Resizer path),
since jQuery's `:visible` can't distinguish a visibility-hidden element
from a shown one.
Measured with a 1098-message AI chat (~10k DOM nodes): expand time on
the sidebar toggle dropped from 752ms → 49.7ms (~15x), scrollTop drift
is 0. Existing suites (mainview:CentralControlBar 50/50, mainview:SidebarTabs
37/37, integration:Navigation 6/6) all green.
…suite Two changes to the new click-dispatch tests added in fa455de: - #showInfileTree test no longer opens test.css. recordCommands hooks EVENT_BEFORE_EXECUTE_COMMAND, which fires whether or not handleShowInTree's activeFile branch runs, so the openFile call added nothing to the assertion but did leak a test.css entry into session-restore state, shifting the nav-history ordering that _validateNavForFiles("test.css", ...) expects. - #searchNav test now closes the Find-in-Files bar via FindInFilesUI._closeFindBar and awaits .modal-bar removal before returning. Leaving the modal open caused full-suite runs to fail subsequent navigation tests with "Active file to be test.css timed out" because the stale modal bar's focus/key handling persisted across closeTestWindow + loadProjectInTestWindow. Nav suite passes 6/6 in isolation across three consecutive runs.
Removing the #showInfileTree and #searchNav click-dispatch specs added in fa455de (and then tried to be patched up in 1fdcf51). Even with no openFile and with explicit FindInFilesUI._closeFindBar cleanup, triggering those clicks still leaked side effects across closeTestWindow() + loadProjectInTestWindow() that shifted the subsequent _validateNavForFiles tests' nav-history ordering, producing deterministic "Active file to be test.css" timeouts only in full-suite runs. Commenting the two specs out was confirmed by the user to restore the suite. The dispatch-on-click coverage these provided isn't worth the flake surface; if it's wanted later it should live in a describe block with isolated beforeAll/afterAll so it can't race the history tests.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.