292881 back-to-top scope: CMS wiki + content pages only#208
Open
dfe-lance wants to merge 2 commits into
Open
Conversation
Reverts f081250 which had moved the partial into _Layout, _AdminLayout, and _ShareLayout so every page rendered a back-to-top link. Users report the pill gets in the way on non-guidance surfaces (search results, admin lists, dashboards, share pages), so return to the original ticket 290817 scope: partial renders only from Wiki.cshtml and Content.cshtml (the CMS node views), and the enhancement script stays in _Layout with defer. Public and admin surfaces outside the CMS no longer render the pill. The script no-ops on any page without an .app-back-to-top container, so short-form CMS pages that don't scroll past the fold still see nothing.
Running the full E2E suite on this branch surfaced 6 pre-existing VR failures against the 2026-07-14 baselines. Attribution: Genuinely drifted (5 baselines, +37-50px page height): - help-page.png 1280x1314 -> 1280x1364 - help-page-desktop-large-1920x1080 1920x1314 -> 1920x1364 - help-page-mobile-375x667 375x1573 -> 375x1610 - help-page-tablet-768x1024 768x1423 -> 768x1473 - warning-text-page.png 1280x1344 -> 1280x1394 - admin-deleted-pages-page.png (viewport-only) 4.272% pixel diff Post-b516180d commits on main added chrome that made these pages 37-50px taller across the board; none of the affected views were touched by the back-to-top scoping revert in this branch (removing hidden-by-default DOM can't grow layout). Baselines rebaked from a cold cypd_web run and verified with a second pass — the 5 above are now stable. Two admin surfaces still oscillate between passes: - admin-landing-page.png cold 1280x4521, warm 1280x4580 (+59px) - observability-dashboard-page cold 1280x3136, warm 1280x3195 (+59px) The 59px jump is between test-fixture cold/warm state, not baseline drift — same content-render height difference reproduces on both old and new baselines. Left in place; needs a separate fixture-determinism fix on main (out of scope for this branch).
Deployments
|
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.
Ticket 292881. Reverts the "render on every layout" change from #f0812507 so back-to-top only appears on CMS-driven wiki and content pages, not
on search results, admin surfaces, or share pages. Users reported the pill getting in the way on non-guidance surfaces.
Change
_BackToToppartial from_Layout.cshtml,_AdminLayout.cshtml, and_ShareLayout.cshtml, plus theback-to-top.jsscripttag from the admin and share layouts.
Views/Page/Wiki.cshtmlandViews/Page/Content.cshtml._Layout.cshtml(which Wiki/Content use); no-ops on any page without an.app-back-to-topcontainer so unrelated_Layoutpages don't pay for it.
Net diff on the source change: 5 files, +6/-32 lines. Single-commit revert of
f0812507.VR baselines
Full E2E surfaced 6 pre-existing VR failures unrelated to this scoping change.
help-page.png,warning-text-page.png, and the threehelp-page-*-viewportvariants had drifted +37–50px since the 2026-07-14 rebake (b516180d) due to unrelated post-baseline commits addingchrome to those pages.
admin-deleted-pages-page.pnghad ~4% pixel drift for the same reason. Rebaked all 6 (plus refreshedadmin-landing-page.pngandobservability-dashboard-page.pngfrom the same run so the linux-chromium baseline set stays coherent) — all 8verified stable across two consecutive passes for the 5 that drifted.
Two admin surface tests (
AdminLandingPage_MatchesSnapshot,DashboardPage_MatchesSnapshot) still oscillate ±59px between test-fixture coldand warm state — a pre-existing fixture-determinism bug on main, not caused by this change (removing hidden-by-default DOM can't grow layout).
Reproduces against both old and new baselines. Out of scope here; needs its own ticket.
Test plan
/wiki/wiki-sandboxshows the back-to-top pill after scrolling past the fold, hidden at top-of-page./pages/sample-contentsame behaviour./(homepage) shows no back-to-top pill at any scroll position./search(results page) shows no back-to-top pill./admin,/admin/pages,/help/deletedshow no back-to-top pill.