The `mailbox.message.show` handler rewrote the hash to `mailBox(sFolder)` --
page 1, no search -- even when the user was already in that folder.
Because the hash of an open message carries the message id and the new one does
not, the two differ, the route fires again, the message is shown again, and the
handler runs again: a loop. Every iteration aborts whatever message list request
was pending, so browsing to page 2 or running a search silently bounces back to
page 1 of the INBOX with an empty search box.
Only navigate when we are not already in that folder. Clicking a new-mail
notification from another folder still takes you to the INBOX; if the message is
not in the current page, the else branch already opens it in the preview pane
without touching the list.
The same unconditional setHash a few lines below, for non-INBOX folders, gets
the same guard.
A plugin that adds a screen has no way to offer a way into it. The
folder list toolbar holds Compose and Contacts, and nothing else can be
added to it, so plugins reach into the UI themselves: polling for an
existing button, replacing its icon and hanging a menu off it. That is
fragile, it varies per plugin, and it puts screens somewhere users do
not look for them.
rl.addNavEntry({icon, title, hash}) appends an entry to that toolbar,
rendered with the same .btn classes so it follows the active theme.
click may be given instead of hash for a popup rather than a route.
Three lines of template, one observableArray, one function, and no
change to existing behaviour when no plugin registers anything.
