giles
a511b21dd2
Reported: on blog.rose-ash.com, home --boosted nav--> a post --click "edit"--> lands on
/tags (a HOME footer link), not /<slug>/edit; subsequent navs stop updating.
Root cause: an innerHTML boost swap uses morph-children, which REUSES DOM nodes in place
(matched positionally when links have no id). The home footer's <a href="/tags"> element is
re-purposed as the post's <a href="/compose-demo/edit"> — its href attribute is rewritten,
but bind-client-route-click had captured the OLD href in its click closure, and the element's
is-processed? mark survived the morph (so boost-descendants skipped re-binding it). Clicking
the reused "edit" link fired the stale /tags closure.
Fix: bind-client-route-click now reads the href FRESH from the element at click time
(dom-get-attr link "href", falling back to the captured value) instead of trusting the
closure. A reused node then always follows its CURRENT href — robust to morph reuse without
needing to clear marks or remove listeners. Recompiled the web stack (.sxbc + manifest).
TEST-FIRST: lib/host/playwright/{boost-nav.spec.js, run-boost-nav-check.sh} reproduces the
exact flow (home -> boosted nav -> click edit -> assert URL is /compose-demo/edit, NOT /tags)
against an ephemeral server. Confirmed RED before the fix (landed on /tags), GREEN after. No
regressions: relate-picker 3/3 (incl. boosted-nav populate) + block-editor 1/1 still pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
38 lines
1.9 KiB
JavaScript
38 lines
1.9 KiB
JavaScript
// Regression for the boosted-navigation link-rebinding bug (reported on blog.rose-ash.com):
|
|
// home --boosted nav--> a post --click "edit"--> lands on /tags (a HOME footer link),
|
|
// not /<slug>/edit. After a boost swap, the swapped-in links carry a STALE binding from
|
|
// the previous page. Run by run-boost-nav-check.sh against an ephemeral host server
|
|
// (serve.sh seeds /compose-demo + the home footer's /tags link).
|
|
const { test, expect } = require('playwright/test');
|
|
|
|
const BASE = process.env.SX_TEST_URL || 'http://127.0.0.1:8914';
|
|
|
|
async function waitReady(page) {
|
|
await expect(page.locator('html[data-sx-ready="true"]')).toHaveCount(1, { timeout: 45000 });
|
|
}
|
|
|
|
test.describe('boosted navigation (browser-only)', () => {
|
|
test('a post link clicked AFTER a boosted nav navigates to the right target (not a stale home link)', async ({ page }) => {
|
|
test.setTimeout(90000);
|
|
// 1) load HOME (its footer has a /tags link — the stale target the bug lands on)
|
|
await page.goto(BASE + '/');
|
|
await waitReady(page);
|
|
await expect(page.locator('a[href="/tags"]')).toHaveCount(1); // home has the /tags link
|
|
|
|
// 2) boosted nav HOME -> the composed post (no full reload)
|
|
await page.locator('a[href="/compose-demo/"]').first().click();
|
|
await expect(page.locator('body')).toContainText('composition object', { timeout: 15000 });
|
|
expect(page.url()).toContain('/compose-demo/');
|
|
|
|
// 3) click the post's "edit" link — brought in by the swap
|
|
await expect(page.locator('a[href="/compose-demo/edit"]')).toHaveCount(1);
|
|
await page.locator('a[href="/compose-demo/edit"]').click();
|
|
await page.waitForTimeout(3000);
|
|
|
|
// 4) it MUST navigate to the edit route (guarded -> the login view is fine, the URL is
|
|
// pushed to /compose-demo/edit), and MUST NOT land on the stale /tags link.
|
|
expect(page.url()).not.toContain('/tags');
|
|
expect(page.url()).toContain('/compose-demo/edit');
|
|
});
|
|
});
|