xnotepp
Scrolling through message list using keyboard stops after message is shown as XNote window grabs focus
Moved from https://www.froihofer.net/bugzilla/show_bug.cgi?id=61
If you use the keyboard to scroll through the message list (cursor up/down) and you reach a message with a note, the XNote window grabs the focus. After this, scrolling is no longer possible until you click on the message list again to give back the focus.
Known workaround: You can disable the automatic popup of the XNote window in the option pane by deselecting "Show note on message selection". After this, you have to manually open a note if you want to see it.
bug or feature? we can have only one of two: focus in xnote: easy editing, or focus in messagelist: easy scrolling.
possible proposal: focus in note on create, leave focus in messagelist on display
This is a great plugin for thunderbird, nice work.
I agree with this issue, there is no need for the focus to held by the xnote window on selecting an email with an xnote attached. I would be happy to select the note if any edits are required. I personally spend send a lot of time humaging through the messagelist, if the focus is lost then as previously pointed out the keyboard shortcuts no longer work to move to the next message etc, unless one uses Alt-Tab to get the focus back to the messagepane. There may be a work around with a plugin like tbkeys, which allow you to define custom keyboard shortcuts. But @opto solution is ideal a preference in xnote options would be perfect.
#9b0dc5c257e059cca82aca6ab46a598cf7bbab33 it is permanently, though, not in a pref: new notes have focus, displayed old messages keep focus in threadpane
This solution causes a regression due to a TB bug: while we can do what we want and the focus is not stolen inside TB, the note is now globally sticky over all Win 10 home windows, always sitting in the top layer. It is displayed everywhere and cannot be put to the background. It sits on top of all other windows, whichever window might be chosen.
In principle, the old code focuses window.opener, as I just saw. But the only thing that does is steal the editing focus from the note, but does not give the focus to the threadview. Maybe get that by id and focus. Will try later.
this truely was tricky and took a few hours due to the alwaysOnTop for popups, which keeps the popup on top of any other application that the user might display while hiding TB. And our old window.opener.focus in the note pulls focus from the note but doesn't give it to threadpane, even if using timeouts, mutation observers, blur, focus, focusout events and whatever you can imagine. In the end, there are two undocumented events in window manager (or was it --watcher) that do the trick. Thanks to some FF desktop development people pointing me there.
In 3.1.7, if you deselect the note window and switch to display the note in messagewindow, you can scroll through the threadtree.
Use the top button to get the note window or the button in messagewindow to toggle between compact/full size