Skip to content

Fix listing page hash lost on a click right after a page change - #15233

Merged
cderv merged 1 commit into
mainfrom
fix/listing-page-hash-firefox-flake
Oct 30, 2026
Merged

cderv merged 1 commit into
mainfrom
fix/listing-page-hash-firefox-flake

Conversation

@cderv

@cderv cderv commented Oct 30, 2026

Copy link
Copy Markdown
Member

When a listing page link is clicked right after the previous page change, the listing shows the new page but the page hash is not written: the URL ends at index.html#. This made the page hash test added in #15214 fail intermittently in firefox on the nightly macOS run.

Root cause

list.js rebuilds the pagination links on every list update. The click handler that writes the page hash, and blocks the links' href="#", was put back on the new links in a setTimeout after each update (src/resources/projects/website/listing/quarto-listing.js:63). A click landing before that timer fires still changes the page through list.js's own listener, but follows href="#".

The timer can't just be dropped: list.js runs updated handlers in reverse registration order, so our handler runs before the links are rebuilt.

Fix

One click listener per listing on its ul.pagination, which list.js keeps across updates, so rebuilt links are covered from the start.

The new test clicks page 2 then page 3 in the same task, so no timer can run in between. It failed in chromium, firefox and webkit before the fix.

No changelog entry, as a user would hardly click fast enough to hit this.

Checklist

I have (if applicable):

  • referenced the GitHub issue this PR closes
  • updated the appropriate changelog in the PR
  • ensured the present test suite passes
  • added new tests
  • created a separate documentation PR in Quarto's website repo and linked it to this PR
AI-assisted PR
  • AI tool used: Claude Code
  • Codebase grounding: local clone
  • Human review: I have reviewed, tested, and verified the AI-generated content before submitting.

Note: autonomous AI agents submitting PRs without human oversight are not permitted — see the Code of Conduct.

list.js rebuilds the pagination links on every update, and the handler
that writes the page hash (and blocks the links' href="#") was only
re-attached in a setTimeout after each update. A click on a rebuilt link
before that timer fired changed the page through list.js but followed
href="#", leaving the URL at index.html# with no page hash. This showed
up as an intermittent firefox failure of the page hash Playwright test on
the macOS nightly run.

The deferral could not simply be dropped: list.js dispatches "updated"
handlers in reverse registration order, so our handler runs before the
pagination plugin rebuilds the links. Instead, attach one click listener
per listing on its ul.pagination, which list.js keeps across updates,
so there is no window without a handler.

The new test clicks page 2 then page 3 in a single task, so no timer can
run between the update and the second click; it failed in chromium,
firefox and webkit before this change.
@posit-snyk-bot

posit-snyk-bot commented Oct 30, 2026 •

Copy link
Copy Markdown
Collaborator

✅ 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

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

@cderv
cderv merged commit e309f3a into main Oct 30, 2026
52 checks passed
@cderv
cderv deleted the fix/listing-page-hash-firefox-flake branch October 30, 2026 13:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants