3 Commits

Include renames

Author	SHA1	Message	Date
Brennan Benson	80e0bee23b	fix(floating-workspace): keep agent launches from moving the main window's tab (#22603) ... * fix(floating-workspace): keep agent launches from moving the main window's tab Launching an agent from the floating workspace's "+" menu switched the main window off whatever chat or editor tab it was showing and onto its terminals. The main window's selection is supposed to move only for the worktree it is showing: browser and editor tab creation, splits, moves and drops all check `activeWorktreeId === worktreeId` before touching it. Two places did not: - `launchAgentInNewTab` called `setActiveTabType('terminal')` without a worktree, which targets the active worktree whatever worktree the launch landed in. - terminal `createTab` wrote the global `activeTabId` for a tab in any worktree. Both now follow the store rule. The launch still selects its tab within its own worktree, which is what the floating panel renders. The floating titlebar button had side-stepped this with an `activate: false` opt-out plus manual selection. That opt-out had no other caller and is removed; the button now launches and focuses like every other entry point. * fix(tabs): scope the remaining launch surface writes to the launch's worktree Three more launch paths create a terminal tab and then call `setActiveTabType('terminal')` without a worktree, which targets whatever worktree is active when the call runs rather than the one the tab landed in: - the paired-host agent launch, after the host's asynchronous create - Session History resume, which can target a worktree the user is not viewing and activates it only afterwards - sleeping-agent resume, which the activation gate runs after asynchronous readiness checks, by which time the user may have moved to another worktree Each now names its worktree, like the local agent launch. The new tab still lands selected when the user switches to that worktree. * test(tabs): pin the paired-host launch scope in its existing web-runtime test * test(tabs): type the left-worktree resume fixture instead of casting it * refactor(tabs): require the worktree that setActiveTabType applies to `setActiveTabType(type, worktreeId?)` quietly fell back to the active worktree when the caller left the worktree out. A caller acting on a tab in another worktree (the floating workspace, a background launch, a reveal that lands after an async step) therefore retyped whatever the main window was showing. The launch paths fixed earlier in this branch were instances of that; 54 other callers still relied on the fallback. The worktree is now a required argument (nullable only for the no-active- worktree case), so every caller states which worktree it means and a new unscoped call fails to compile. Each call site passes the worktree of the tab it acts on; where that is by construction the active worktree (shortcuts, palette, tab strip), the result is unchanged. `activateTabAndFocusPane` resolves the tab's owning worktree the same way `setActiveTab` does. End-to-end helpers that drive the store directly pass the active worktree, which keeps their previous behaviour. * fix(floating-workspace): let the floating New Terminal activate its own tab The floating "+" New Terminal created its tab with `activate: false` and then selected it with `activateTab`, because creating an active tab used to write the main window's selected tab even for another worktree. `createTab` now activates a tab only within its own worktree's group unless that worktree is the one on screen, so the workaround is no longer needed. Creating the tab active also moves the floating workspace's remembered tab to the new one; before, it stayed on the previously selected floating tab, which auto-acknowledge reads to decide which floating agent the user is looking at. * refactor(floating-workspace): route every floating New Terminal through one creator The floating "+" New Terminal had stopped deferring activation, but Cmd+T with the floating panel focused still went through a separate creator that created the tab inactive and activated it by hand, which left the floating workspace's remembered tab on the previous tab. Both now call createFloatingWorkspaceTerminalTab, which creates the tab active in its own group and focuses it. * docs(tabs): say why an unowned tab id keeps the on-screen worktree scope	2026-09-24 10:54:43 -07:00
Neil	1f2e18acc1	fix(e2e): repair seven specs whose assertions drifted from shipped behavior (#13785) ... * fix(e2e): repair seven specs whose assertions drifted from shipped behavior The E2E suite could not collect at all until #13758, so these seven had been failing unobserved. Each is a stale test, not a product defect — verified individually against src/ rather than by making the assertion pass. - worktree-jump-palette-filter: the palette placeholder gained chats and terminals. Hoisted to one SEARCH_PLACEHOLDER const. - tab-create-entry-file-paths: matched the omnibox by its translated aria-label. Switched to aria-controls, which is structural and unlocalized. - browser-local-https-certificate-trust: once a load settles, the toolbar reload button relabels itself "Retry" alongside the failure overlay's own Retry, so the slot-wide locator hit two elements and failed strict mode. The test only ever passed inside the window where the toolbar still read "Stop". Narrowed by visible text; the icon button has none. - repro-7732-gitlab-checks-job-details: the activity-bar label carries a failure suffix ("Checks — Error"), which an exact-name match stops seeing precisely when the checks under test fail. Anchored regex, and bounded the click so the poll retries instead of hanging on a label that flips mid-action. - floating-tab-rename: the panel's open flag is persisted, so after the restart the helper's blind toggle closed the panel it was about to assert on. Made it idempotent. - github-created-issue-start-prefill: starting an issue now routes through the quick-create composer, so the launch command only forms once that is submitted. The spec now drives it. - ssh-config-host-import: P6 waited on "All hosts already in Orca", a string that exists nowhere in src/ and never could have matched. P7 required the tombstoned host to be absent, but listing it behind a "Removed from Orca" badge is deliberate — see the rationale at ssh-config-host-picker.ts:54 and the unit test already pinning it. Both retargeted; P7 still proves the host is excluded from bulk re-adoption, which is what it was for. Verified locally: all seven pass. github-created-issue-start-prefill cannot be verified on a machine whose gh resolves to an Orca terminal-attribution shim, since hydrateShellPath puts that ahead of the fixture's fake gh; CI has no shim. Three further failures are NOT addressed here. Adversarial review found the obvious test-side fix for each would have masked a real product bug, so they are being fixed in the product instead. * fix(e2e): configure the issue spec's git remote before Electron launches The spec added origin inside the test body, after the orcaPage fixture had already launched the app and added the repo. "New GitHub issue" is disabled when no repo is task-eligible, and eligibility is decided by the git remote probe alone: repos.add runs detectRepoIconAndUpstream, and a settled "no remote" writes gitRemoteIdentity = null, which is the ineligible marker. Background enrichment then suppresses re-probing that location for five minutes, so a remote added afterwards can never recover the button. It passed only when the shared seeded repo happened to already carry an origin from an earlier spec in the same worker — github-cli-stall-repro adds one, source-control-create-pr-intent-switch removes one — which is why it passed in the sharded lane and failed in the changed-specs lane. Moved to test.beforeAll, whose worker-scoped testRepoPath runs before the test-scoped Electron fixtures. Reproduced the failure against a fresh origin-less repo, then confirmed the fix on the same, including --repeat-each=2. Note the earlier attribution was wrong: the local failure at this line was never the gh attribution shim. The button's enabled state reads `git remote -v` and never consults gh, so a shim can only bite later, at issue creation.	2026-08-11 03:07:44 -07:00
NeilandJinjing	6e91ca6c0e	fix(browser): local HTTPS Try HTTPS + cert proceed (#8454) (#9104) ... Co-authored-by: Jinjing <6427696+AmethystLiang@users.noreply.github.com>	2026-07-16 19:11:34 -07:00