Skip to content

add keyboard shortcuts for quick navigation#644

Open
shanestillwell wants to merge 1 commit intoaxllent:developfrom
shanestillwell:keyboard-shortcuts
Open

add keyboard shortcuts for quick navigation#644
shanestillwell wants to merge 1 commit intoaxllent:developfrom
shanestillwell:keyboard-shortcuts

Conversation

@shanestillwell
Copy link

Keyboard shortcuts added:

  • j / ArrowDown - Navigate to next message
  • k / ArrowUp - Navigate to previous message
  • Escape / u - Return to inbox/search (MessageView only)

Keyboard shortcuts added:
* j / ArrowDown - Navigate to next message
* k / ArrowUp - Navigate to previous message
* Escape / u - Return to inbox/search (MessageView only)
@axllent
Copy link
Owner

axllent commented Feb 14, 2026

Hi @shanestillwell - I appreciate your idea and the effort put into this implementation! However, I’ve noticed a few usability issues that I believe could be addressed, and I have some potential solutions.

  1. Scrolling in the Messages List: The current up/down arrows are necessary for message/page scrolling. With your PR, scrolling now requires a mouse or extreme keyboard shortcuts like Page Up/Down. Instead of opening the previous/next message, could we map the keys to focus() on the previous/next message in the list? This way, users would need to press Enter to open a message.
  2. Navigation in Message View: In the message view, the key mappings should highlight the previous/next message in the side navigation without opening it immediately (again requiring Enter to access). This aligns with the previous point.
  3. Returning to the Messages List: After escaping from a message view back to the messages list (e.g., inbox), the view defaults to the first message. There’s a feature in Mailpit that focuses on the last opened message when selecting "Return to Inbox." Could we implement a similar logic here to avoid returning to the top every time?
  4. Keyboard Functionality in Iframe: When clicking anywhere within an HTML message view, all keyboard functions are bypassed since the message is displayed in an iframe. I’m uncertain if we can pass these key mappings through the iframe; your insight here would be appreciated.

Do you agree with these suggestions? If not, I’d love to discuss further. If you do, could you assist with implementing these changes? I’m currently in the hospital recovering from shoulder surgery (with another procedure tomorrow), so I may not be able to provide timely support.

@shanestillwell
Copy link
Author

@axllent Hope you heal up quickly.

I've been playing with some of your recommendations.

  1. This is pretty easy to do and can revert to what you're suggesting.
  2. I'm not sold on the double key in the MessageView. Having to hit ArrowDown then Enter feels clumsy. If you're in the MessageView, what's the point of just highlighting the next message? It will be confusing since you'll be seeing one message, but the next message is highlighted in the left message selector. Instead, Up/Down should also show that email. Am I being clear?
  3. This is possible, but I saw a sort of edge case where this sort of breaks. On the ListView, the arrows on the top right go to the next page (e.g. next 50 messages). While in the MessageView, those same arrows just navigate to the next email. On the MessageView, the concept of pages is gone. So when going back, we need to keep track of which page that message is on and automatically go back to that page. Something I'm still trying to figure out how to accomplish.
  4. Here we are mostly out of luck. iFrames capture the cursor, and only a click outside the frame frees it again for keyboard navigation. 😞

Stay tuned. Thanks again for consider this update.

@axllent
Copy link
Owner

axllent commented Feb 18, 2026

@axllent Hope you heal up quickly.

Thank you. I'm still in hospital, but am recovering well - I'm just doing one-handed typing which is rather slow :) Fortunately I have some time to think though!

I've been playing with some of your recommendations.

1. This is pretty easy to do and can revert to what you're suggesting.

Great!

2. I'm not sold on the double key in the MessageView. Having to hit ArrowDown then Enter feels clumsy. If you're in the MessageView, what's the point of just highlighting the next message? It will be confusing since you'll be seeing one message, but the next message is highlighted in the left message selector. Instead, Up/Down should also show that email. Am I being clear?

I think I understand your point, however if I've opened the first message in the list, and then want to open the 5th, with your approach I would then also have to then open messages 2->4 just to get to the 5th. The similar logic / reasoning applies to the MailboxView/SearchView.

You could potentially map ⬅️ ➡️ (left/right arrow keys) in the MessageView to go to the previous/next message, in which case I would then also suggest applying the same logic to the pagination views. This would make far more sense to me and would provide you with what you're after (other than requiring ⬅️ ➡️ instead (and whatever the emacs (?) variation of that is.

Thoughts?

3. This is possible, but I saw a sort of edge case where this sort of breaks. On the ListView, the arrows on the top right go to the next page (e.g. next 50 messages). While in the MessageView, those same arrows just navigate to the next email. On the MessageView, the concept of pages is gone. So when going back, we need to keep track of which page that message is on and automatically go back to that page. Something I'm still trying to figure out how to accomplish.

Yeah, there are a few issues behind that logic - and not necessarily (easily?) solvable depending on how you got to the message either (eg: if you just opened it via the URL, then Mailpit does not know where to return to, so will return you to the inbox). To prevent and duplication of logic, maybe it should just trigger the same function as the "Return in inbox/search" button (goBack() within the vue app) - then I can always try refine that logic in the future if it becomes problematic. If you don't have access to that method, then maybe just trigger a click() event on the button instead and let the app work it out.

4. Here we are mostly out of luck. iFrames capture the cursor, and only a click outside the frame frees it again for keyboard navigation. 😞

Don't worry about the iframe then (ignore it) - I expect there will be a workaround if we bubble up the escape/u event to the parent, however I'd need to look at that whole piece of code again because there are security implications & restrictions with JS in the iframe.

Stay tuned. Thanks again for consider this update.

Sounds great, thank you. If you have any further questions, of need more clarity on the point(s) above, just yell out.

@axllent axllent mentioned this pull request Feb 19, 2026
@axllent axllent force-pushed the develop branch 3 times, most recently from b3bb6fa to 7bb330a Compare March 2, 2026 09:38
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