Created attachment 370667 [details]
Stack trace from adjustment value-changed

The first time a text/plain message part is clicked (left, or primary, button) in either the preview or the message window, it scrolls to place it at the top of the page (if there is enough text to make scrolling possible). In particular, the header block is scrolled off the top of the page.

The UX is bad because scrolling is not an expected consequence of clicking. It's especially annoying if clicking on an URL: the URL is highlighted when the pointer moves over it, but scrolling moves the text so that different text is under the pointer when Balsa receives the click. That could even be a privacy/security problem, as a different URL could be under the pointer, one that the user specifically would not want to visit. It's also annoying if clicking to select some text, since the wrong text would be selected if the user didn't move the pointer appropriately.

The problem, loosely, is that the GtkTextView event handler grabs the keyboard focus, then calls gtk_container_set_focus_child on all the text-view's parent containers, and gtk_container_real_set_focus_child does the scrolling. The attached stack trace shows the gory details (note: Balsa was built in a jhbuild shell, so the Gtk3 version is the current gtk+-3-22 branch at GitLab); the "value-changed" signal of the GtkScrolledWindow's vertical GtkAdjustment was caught to capture the trace.

It's not clear that any of those steps is a bug, but the combined effect is a bad UX. I'm inclined to raise it as a Gtk issue on GitLab, but it's not clear that that would lead to any changes. One workaround is for Balsa to block GtkTextView from seeing the click, but that could have unintended consequences.

Discussion welcome!