fix(edit-button): send the page the editor was on to the CMS

[kirtesh-cstk]

Sends the page an editor was on to the CMS, so Live Preview can stay on it.

Why

The edit button links to the entry and the field, and says nothing about the page it was clicked from. The CMS cannot work that out from the entry alone. A referenced entry can be rendered on several pages, and a nested one has no page among the entries that directly reference it.

Without it the Live Preview panel has to guess, and falls back to the environment base URL when the guess fails.

What changed

generateRedirectUrl appends the current page as preview-url. The CMS already reads that parameter, so nothing is needed on its side to accept it.

getCurrentPageUrl reads window.location and strips live preview's own query parameters (live_preview, content_type_uid, entry_uid, preview_timestamp, preview_variant, cslp-buttons) while keeping the site's own query string. It returns an empty string outside a browser or if the URL cannot be parsed, and the parameter is then omitted.

This reads window.location, so it does not depend on how a site tags its markup.

Compatibility

An older CMS ignores a parameter it does not use, so the link keeps working. The paired CMS change treats a missing preview-url as no page information and resolves the page the way it does today.

The in-iframe path is untouched. Only the standalone website case, where the button opens a new tab, gains the parameter.

Tests

Four new tests for getCurrentPageUrl: a plain page URL, live preview parameters stripped, the site's own query string kept, and the path preserved.

Three existing tests in editButtonAction.test.ts assert the exact redirect URL and were updated for the new parameter.

Full suite: 703 tests across 104 files, all passing.

Note for reviewers

The page URL now appears in the CMS URL and in browser history, including any query string the site carries. Worth a look if pages in your setup put anything sensitive in query parameters. Trimming to origin and path would avoid it, at the cost of preview accuracy for routes driven by the query string.

---

🤖 Generated with Claude Code

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	0	25	✅ Passed
🟡 Medium Severity	1	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	67.4%	2533 / 3758
🔵	Statements	66.27%	2574 / 3884
🔵	Functions	64.66%	452 / 699
🔵	Branches	62.01%	1538 / 2480

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/livePreview/editButton/editButton.ts	96.66%	89.59%	100%	97.74%	109-110, 181, 268, 413, 451, 573, 601, 648
src/utils/getCurrentPageUrl.ts	70%	75%	100%	77.77%	31, 40-41

Generated in workflow #881 for commit 7cb20e8 by the Vitest Coverage Report Action

[contentstackMridul]

Approving. Small, self-contained, and safe to merge ahead of release-preview-client#578. The panel ignores preview-url when it can't split it, so there's no ordering constraint.

All checks green: test (7m3s), CodeQL, Analyze (javascript), the three Snyk checks, and security SCA/license/policy.

Two cleanups, neither blocking.

The live-preview parameter list now exists twice. getCurrentPageUrl.ts:117 introduces LIVE_PREVIEW_QUERY_PARAMS, and utils/addLivePreviewQueryTags.ts:7-11 already encodes the same concept inline (live_preview, content_type_uid, entry_uid, preview_timestamp) as the exact inverse operation. Two lists for one idea drift apart: add a parameter to the copier and the stripper won't know about it, and the symptom would be a stray parameter riding back into preview-url. One exported constant used by both would settle it.

preview_variant isn't a real parameter. It's in the strip list but appears nowhere in src outside that array. cslp-buttons and the other three all check out. Harmless, but it reads as protection that doesn't exist.

I also checked the strip list against what the panel actually injects: createLivePreviewUrl sets live_preview, content_type_uid and entry_uid (livePreviewUtils.ts:369-371), and stripLivePreviewQueryParams confirms the same three. The SDK's list covers all of them with room to spare, so nothing leaks back into preview-url.

On correctness: the input is window.location.href, guarded for a missing window, wrapped in try/catch, returning "" on failure, and the call site omits the parameter when it's empty, so the degradation path is the current published behaviour. searchParams.delete on an absent key is a no-op, append encodes the value, and the CMS decodes it through URLSearchParams, so the percent-encoded value survives the trip intact.

The tests get the interesting distinction right: preview parameters dropped, the site's own ?q=fountains kept. That's the case a naive url.search = "" would have broken, and nobody would have noticed until a customer with faceted search complained. Keeping getCurrentPageUrl pure (taking nothing, reading only window.location) is what makes it trivially testable, and the three updated editButtonAction tests show the parameter is genuinely on the wire rather than assumed.