Skip to content

fix(sidebar): render nav items as real links so middle-click works - #3601

Open
itsdaveit wants to merge 1 commit into
frappe:developfrom
itsdave-de:fix/sidebar-nav-links
Open

fix(sidebar): render nav items as real links so middle-click works#3601
itsdaveit wants to merge 1 commit into
frappe:developfrom
itsdave-de:fix/sidebar-nav-links

Conversation

@itsdaveit

Copy link
Copy Markdown

Problem

Sidebar entries cannot be opened in a new tab. Middle-click, ctrl/cmd-click and the browser's "open link in new tab" all do nothing, because every item renders as a <button> — there is no link target for the browser to act on. The entries are also not exposed as links to assistive technology.

Cause

frappe-ui's SidebarItem already renders a RouterLink whenever a to prop is present and only falls back to <button> otherwise. AppSidebar never passes to, although every navigable item already knows its route target — it just used it inside the click handler (router.push).

Change

Pass the route target through as to for the three navigable item groups: nav items, saved views and the mobile notifications entry. Navigation is then performed by the router link itself, so selectItem() keeps only its side effects (setting the active item immediately, before the route settles, plus the caller's hook).

Items that have no route target — search and the notifications toggle — are unchanged and keep rendering as buttons.

Notes

  • No visual change; SidebarItem renders identical markup in both branches.
  • activeItem is still set eagerly for instant highlighting, and the existing route watcher keeps it in sync.
  • Removes the now-unused useRouter/RouteLocationRaw imports.

Testing

Verified in a production Helpdesk instance: middle-click, ctrl-click and the context menu now open tickets, customers, contacts and saved views in a new tab; regular clicks and active-state highlighting are unaffected.

@mergify

mergify Bot commented Jul 20, 2026

Copy link
Copy Markdown

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

  • Queue this pull request

@greptile-apps

greptile-apps Bot commented Jul 20, 2026

Copy link
Copy Markdown
Contributor

Confidence Score: 5/5

Safe to merge — the change is narrow, purely additive, and has no effect on visual output or existing click behaviour.

Only one file changed. Navigation now happens through the router link instead of router.push inside the click handler, but the outcome is identical. Items without a to prop continue rendering as buttons. No logic paths are removed that weren't replaced by an equivalent mechanism.

Files Needing Attention: No files require special attention.

Reviews (2): Last reviewed commit: "fix(sidebar): render nav items as real l..." | Re-trigger Greptile

Sidebar items were rendered as <button> because AppSidebar never passed a
`to` prop, even though every navigable item already knew its route target
and frappe-ui's SidebarItem renders a RouterLink whenever `to` is present.

As a result none of the sidebar entries could be opened in a new tab —
middle-click, ctrl/cmd-click and "open link in new tab" all did nothing,
and the items were not exposed as links to assistive technology.

Pass the route target through as `to` for nav items, saved views and the
mobile notifications entry. Navigation is then handled by the router link
itself, so selectItem() only keeps its side effects (immediate highlight
and the caller's hook). Items without a route target — search and the
notifications toggle — keep rendering as buttons.
@itsdaveit
itsdaveit force-pushed the fix/sidebar-nav-links branch from 8eae226 to 995f625 Compare July 28, 2026 23:11
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.

1 participant