I have:
Bug description
A dashboard navbar is a Bootstrap tablist, so a keyboard user moves between pages with the arrow keys, not with Tab. The arrow keys change the visible page, but none of the other work that a mouse click does happens.
Everything the navbar needs is in a click listener (quarto-dashboard.js#L125-L142). Bootstrap activates a tab from an arrow key without dispatching a click, so that listener never runs.
Two things are skipped:
- The URL is not updated.
setLocation() never runs, so the address bar still shows the page the reader arrived on. Bookmarking or sharing captures the wrong page, and Back and Forward do not step through page changes made with the keyboard.
- The page flow is not updated.
updatePageFlow() never runs, so a page marked scrolling="true" keeps the fill layout of the previous page. This one is visible on screen.
A fix could move the work to shown.bs.tab, which fires for both paths. That hook looks safe: showPage() sets the active classes directly rather than through the Bootstrap tab API, so it emits no shown.bs.tab and a listener there will not re-enter on popstate. I verified this by calling QuartoDashboardUtils.showPage() with a listener attached; no event fired.
Please keep #14818 and #14819 passing when fixing this. Their regression tests are in tests/integration/playwright/tests/dashboard-hash-navigation.spec.ts.
Part of #8706.
Steps to reproduce
---
title: "Keyboard page navigation"
format: dashboard
---
# Page One
## Row
Content for page one
# Page Two {scrolling="true"}
## Row
Content for page two
- Render the document and open the HTML output.
- Press Tab until the "Page One" navbar tab has focus.
- Press the Right arrow key.
Actual behavior
The visible page changes to "Page Two", but the URL keeps its original hash and the scrolling layout is not applied.
Measured in Chromium on Quarto 1.10.18:
|
arrow key |
mouse click |
click on the tab |
no |
yes |
show.bs.tab / shown.bs.tab |
yes |
yes |
| URL hash |
"" |
"#page-two" |
body.dashboard-fill |
true (wrong) |
false |
.quarto-dashboard-content.dashboard-scrolling |
false (wrong) |
true |
Expected behavior
Arrow key navigation matches mouse navigation. The URL becomes #page-two, so the page can be bookmarked and shared and Back returns to the previous page. The scrolling layout is applied.
Your environment
- Positron 1.124.0
- macOS 26.5.2 (build 25F84)
Quarto check output
Quarto 1.10.18
[✓] Checking environment information...
Quarto cache location: /Users/charlottewickham/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
Pandoc version 3.10.0: OK
Dart Sass version 1.101.0: OK
Deno version 2.7.14: OK
Typst version 0.15.1: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
Version: 1.10.18
Path: /Applications/quarto/bin
[✓] Checking tools....................OK
TinyTeX: v2026.04
Chrome Headless Shell: 150.0.7871.115
VeraPDF: 1.28.2
[✓] Checking LaTeX....................OK
Using: TinyTex
Path: /Users/charlottewickham/Library/TinyTeX/bin/universal-darwin
Version: 2026
[✓] Checking Chrome Headless....................OK
Using: Chrome Headless Shell installed by Quarto
Path: /Users/charlottewickham/Library/Application Support/quarto/chrome-headless-shell/chrome-headless-shell-mac-arm64/chrome-headless-shell
Version: 150.0.7871.115
[✓] Checking basic markdown render....OK
[✓] Checking R installation...........OK
Version: 4.5.2
Path: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources
LibPaths:
- /Users/charlottewickham/Library/R/arm64/4.5/library
- /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library
knitr: 1.51
rmarkdown: 2.30
[✓] Checking Knitr engine render......OK
[✓] Checking Python 3 installation....OK
Version: 3.12.2
Path: /Users/charlottewickham/.pyenv/versions/3.12.2/bin/python3
Jupyter: 5.9.1
Kernels: python3
[✓] Checking Jupyter engine render....OK
[✓] Checking Julia installation...
Investigation was AI-assisted, grounded in a local clone (per CONTRIBUTING.md).
I have:
Bug description
A dashboard navbar is a Bootstrap tablist, so a keyboard user moves between pages with the arrow keys, not with Tab. The arrow keys change the visible page, but none of the other work that a mouse click does happens.
Everything the navbar needs is in a
clicklistener (quarto-dashboard.js#L125-L142). Bootstrap activates a tab from an arrow key without dispatching a click, so that listener never runs.Two things are skipped:
setLocation()never runs, so the address bar still shows the page the reader arrived on. Bookmarking or sharing captures the wrong page, and Back and Forward do not step through page changes made with the keyboard.updatePageFlow()never runs, so a page markedscrolling="true"keeps the fill layout of the previous page. This one is visible on screen.A fix could move the work to
shown.bs.tab, which fires for both paths. That hook looks safe:showPage()sets theactiveclasses directly rather than through the Bootstrap tab API, so it emits noshown.bs.taband a listener there will not re-enter onpopstate. I verified this by callingQuartoDashboardUtils.showPage()with a listener attached; no event fired.Please keep #14818 and #14819 passing when fixing this. Their regression tests are in
tests/integration/playwright/tests/dashboard-hash-navigation.spec.ts.Part of #8706.
Steps to reproduce
Actual behavior
The visible page changes to "Page Two", but the URL keeps its original hash and the scrolling layout is not applied.
Measured in Chromium on Quarto 1.10.18:
clickon the tabshow.bs.tab/shown.bs.tab"""#page-two"body.dashboard-filltrue(wrong)false.quarto-dashboard-content.dashboard-scrollingfalse(wrong)trueExpected behavior
Arrow key navigation matches mouse navigation. The URL becomes
#page-two, so the page can be bookmarked and shared and Back returns to the previous page. The scrolling layout is applied.Your environment
Quarto check output
Investigation was AI-assisted, grounded in a local clone (per CONTRIBUTING.md).