feat(ui): add global and context-aware keyboard shortcuts

[SudhanshuMatrix]

This PR standardizes keyboard navigation shortcuts in Gitea's UI to build strong muscle memory and improve power-user workflow.

Pressing ? on any page opens a responsive help modal listing the available shortcuts. The modal and the shortcuts themselves are completely context-aware and will only be active/visible when they are relevant to the current page.

Features

• Help Modal: Press ? to view all available shortcuts for the current page context. Press Esc to close it.
• Global Navigation:
  • g i: Go to Issues (context-aware: repository issues vs. global issues)
  • g p: Go to Pull Requests (context-aware: repository pulls vs. global pulls)
  • g d: Go to Dashboard
• Repository Context:
  • g c: Go to Code
  • s: Focus Search box
  • w: Open Branch/Tag switcher
  • t: Activate File Finder
• File View Context:
  • y: Expand URL to permanent commit hash (Permalink)
  • b: Toggle Git Blame view

Technical Details

• Extends the existing shortcut framework in shortcut.ts.
• Implements keyboard_shortcuts_modal.tmpl included in the base footer, reusing Gitea's native .ui.modal CSS components.
• Modularized styling placed in web_src/css/modules/shortcut.css.
• Event handlers are attached dynamically in shortcut.ts to fully comply with Gitea's strict Content Security Policy (script-src 'self'), removing all inline onclick attributes.
• Smart getRepoLink() DOM inspector in shortcut.ts guarantees robust repository routing context across all views.
• Failsafes built into shortcut.ts to ensure shortcuts do not trigger while typing in inputs, textareas, or contenteditable elements.

Screenshot

[wxiaoguang]

It can't be right to flood such a large template into every page. It isn't used for more than >99% time.

[SudhanshuMatrix]

GitHub does show it on every page, so I was just trying to mimic that behavior. Appreciate the suggestion. Which pages do you think it makes sense to limit it to?

[delvh]

I think @wxiaoguang meant that there should be one call to setup this keyboard shortcut thingy.
Not one per template.

I don't think he meant limiting it to certain pages.

[SudhanshuMatrix]

Thanks for the clarification @delvh once @wxiaoguang gives it a go I will the update the PR

[wxiaoguang]

It's quite complicated, and there could be different approaches.

The basic principle is: don't render unnecessary (unused) content into every page. The help dialog can be shown on every page, but it doesn't mean every page should have the HTML code generated for every request.

To show a help dialog, maybe you can use a fetch request to get the content dynamically, maybe you need to collect the supported shortcuts on the current page, etc. You can also learn from other web applications, design the UI/UX with a clean and maintainable approach.

[SudhanshuMatrix]

Thanks @wxiaoguang I have Updated the PR I removed the server-side modal template to keep page loads lightweight, and instead made JavaScript dynamically scan the page for active shortcuts and generate the help modal in browser memory only when requested.

[wxiaoguang]

You should never just keep copying&pasting the code.

You should add the shortcut to the element directly, let the framework handle the cases, but not make this file know everything.

[SudhanshuMatrix]

Thanks for the review I have updated the PR to address this

[SudhanshuMatrix]

Hi @silverwind, sorry for the ping. If you have a few minutes, I'd really appreciate your thoughts on this new UI whenever you have the time. Thanks

[silverwind]

My overall thought on the UI is that fomantic modal look dated and should be replaced with something better (likely <dialog> based modal), but that's a big refactor and out of scope here.

Generally I do think gitea needs global shortcuts but care needs to be taken that it does not interfere with the other existing shortcut mechanisms, e.g. it needs a clean architecture.