CLUE-622: Fix flaky test--Keep Copy to Workspace disabled until the workspace document loads

[kswenson]

What this fixes

Copy to Workspace could silently do nothing. With tiles selected in a Problems tab, clicking the button before the workspace document finished loading copied nothing — no error, no feedback, the click simply discarded. The window is short, so people rarely notice: they click again and it works. The Cypress regression suite clicks the instant the button looks actionable and hit the window often enough that the resulting failure was written off as flake.

After this change the button reports its true state. It stays disabled while there is nothing to copy into, and becomes enabled as soon as there is — so the click either works or is visibly unavailable.

Three defects, stacked

Each one hid the next, which is why this took a while to pin down:

1. persistentUI.problemWorkspace.primaryDocumentKey is undefined for a window after load — no workspace document is registered to copy into yet.
2. isButtonDisabled compared document?.key === primaryDocumentKey. A section toolbar has no document of its own, so while the key was also undefined this was undefined === undefined, and Copy to Workspace flipped to disabled. ToolbarButtonComponent.handleClick returns early when disabled, so the click was dropped silently.
3. With that corrected the click reached handleCopyToWorkspace, which guards on primaryDocument?.content and returned without copying — silently again.

Why the test could not see it

The spec guarded the click with:

canvas.getCopyToWorkspaceButton().should('not.have.attr', 'disabled');

Toolbar buttons report their state via aria-disabled and never render a bare disabled attribute, so this assertion passed instantly regardless of the button's real state. Cypress never waited, and clicked straight into the window.

This check has been vacuous since it was added in April 2025 — the element was a <div> then, with no disabled attribute either. It is not fallout from the later accessibility work that made these buttons real <button> elements.

Changes

• src/components/toolbar.tsx — require a primary document key before treating a document as the primary document, and keep Copy to Workspace disabled until a loaded primary document exists.
• cypress/e2e/functional/document_tests/tiles_copy_test_spec.js — assert aria-disabled, so Cypress waits for the button to become actionable.
• src/components/toolbar.test.tsx — unit tests pinning button state across three cases: no primary key, key set but not yet loaded, and loaded.

Verification

Check	Result
Cypress spec loop, retries=0	4 of 6 runs failed before; 7 of 7 passed after
Full jest suite	3978 passed, 0 failures
npm run check:types, eslint	clean

Both production changes are pinned: reverting the fix makes two of the new unit tests fail. The failure signature Found '22', expected '32' was confirmed to be exactly the no-copy state by removing the click entirely and getting the same count.

For the reviewer

This makes Copy to Workspace correctly disabled during a window on load where it previously appeared enabled. That is the intended behavior, but it is a visible change to button state, so it deserves an eye.

Jira: CLUE-622

🤖 Generated with Claude Code

https://claude.ai/code/session_01462X5PX8pREGYLLy9fSr6m

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.32%. Comparing base (4941cfd) to head (728bb45).
⚠️ Report is 17 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2987   +/-   ##
=======================================
  Coverage   86.31%   86.32%           
=======================================
  Files         994      994           
  Lines       56836    56840    +4     
  Branches    15056    15059    +3     
=======================================
+ Hits        49059    49065    +6     
+ Misses       7757     7755    -2     
  Partials       20       20           

Flag	Coverage Δ
cypress	?
cypress-regression	71.18% <100.00%> (+<0.01%)	⬆️
cypress-smoke	41.17% <100.00%> (+<0.01%)	⬆️
jest	57.70% <80.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

Keeps Copy to Workspace disabled until its destination document is loaded, preventing silently discarded copy actions.

Changes:

• Corrects toolbar disabled-state logic for section toolbars and unloaded workspaces.
• Adds unit coverage for primary-document lifecycle states.
• Fixes Cypress to assert the actual aria-disabled state.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/components/toolbar.tsx	Gates copying on a loaded primary document.
src/components/toolbar.test.tsx	Tests toolbar states before and after document loading.
cypress/e2e/functional/document_tests/tiles_copy_test_spec.js	Waits for the accessible enabled state before clicking.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[cypress]

collaborative-learning    Run #20204

Run Properties:   Passed #20204  •  728bb45839: docs: note that the section toolbar test config is synthetic

Project	collaborative-learning
Branch Review	CLUE-622-copy-to-workspace-disabled-state
Run status	Passed #20204
Run duration	03m 41s
Commit	728bb45839: docs: note that the section toolbar test config is synthetic
Committer	Kirk Swenson
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	0
Skipped	0
Passing	4
View all changes introduced in this branch ↗︎

[emcelroy]

Looks good 👍 A review generated with Claude only raised a few nits. Only one seemed at all worth mentioning, and even that is probably OK to ignore if you want. See below.

renderSectionToolbar builds copyConfig by hand (toolbar.test.tsx:175-181) including an edit button and passes it directly, bypassing myResourcesToolbar() and its filter. That's fine as a unit test of isButtonDisabled, and it does pin the guard. But the test name at line 240 could lead a later reader to believe section toolbars show an Edit button. A one-line comment noting the config is synthetic, and that production section toolbars filter Edit out, would prevent that.