736899 - Navigating to the next unread message across folders closes the message tab

Status: NEW

(Thunderbird :: Toolbars and Tabs, defect)

Description

[Jim Porter (:squib)]

Attachment: A seemingly-working patch

If you have a message open in a tab and hit "N" to go to the next unread message, and that message is in another folder, the tab just closes. It seems that it's being overly-aggressive about not letting the message tab have no message inside.

Here's a patch that seems to work, but may cause chaos somewhere else...

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 607029 [details] [diff] [review]
A seemingly-working patch

I think this requires UX-signoff that we want a message tab to be this feature-ful.  My mental model has been that we can think of a message tab as having forked off of the current thread-pane view and the set of messages is limited to those originally under display.

Letting a message tab navigate folders adds all types of possible semantic wrinkles that are unpleasant.  If the original view you were looking at had a quick-search active, does the quick search get applied to the new folder?  What if the navigated-into folder had a persisted mail-view associated with it?

I would suggest it's better to have folder navigation rule out cross-folder navigation for message tabs by disabling commands or constraining them.

If Blake is cool with the folder navigation, then this patch would obviously need a new mozmill test case for cross-folder navigation from a message tab.  This would include test cases for all of the relevant permutations (mailview, quick filter variants, probably involving an XFVF with enough folders or whatever that ensures it goes async so we have to potentially wait async for the all-messages-loaded notification).  Also, please provide a reference to a cleanish mozmill try server test run with such a review request.

Comment 2

[Jim Porter (:squib)]

Well, on the one hand, I never navigate like this, so I wouldn't miss it if we just outright disabled next/previous in message tabs, but I'm sure people would grouse if we did that. I do think we should do something in this bug though, since the current UX is pretty bad. Disabling cross-folder navigation but keeping in-folder navigation seems like an ok compromise.

Bug 718341 is also somewhat related, in that the synthetic view for restored message tabs *entirely* disables the next/previous commands.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Jim Porter (:squib) from comment #2)
> Bug 718341 is also somewhat related, in that the synthetic view for restored
> message tabs *entirely* disables the next/previous commands.

Yeah, that one also plays into the question of "what are the semantics of message tabs?" since we only persist the URI of the message and make no attempt to persist the invisible state that is a result of cloning the message store.  I think the limited persistence makes sense unless the UI of message tabs changes so that they become effectively a "maximized" three-pane that can be un-maximized back to a 3-pane.

Comment 5

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 607029 [details] [diff] [review]
A seemingly-working patch

So, it seems to me that having a message in a new tab be a weirdly-hidden 3-pane is a bit of an implementation detail.  With my user-hat on, I'm slightly surprised to hear that navigation works at all, given how hard it is to see what you'll be navigating to, and how much it feels like the message is a document in itself.  In a related situation, opening a link in a new tab in Firefox doesn't copy over all your history.  So these things all lead me to say that we should disable navigation in messages in tabs entirely.

Of course, I'm also hesitant to break the use-cases of the people who use tabs as their primary navigation mechanism.  And sadly, we still don't know how many people use tabs for messages, or whether or not they navigate within them, so that makes it harder to decide (or more accurately, harder to justify the decision).

And finally, the message window already lets us navigate between folders and accounts, so having the message tab work differently from it seems more confusing than helpful, particularly when we plan on being able to tear off a message tab, and have it be a message window.  So I think that finally tilts me over to the ui-r=me side.  But wow, did that ever take a long time to get to.

To answer the edge cases that Andrew brought up, I think the guiding principle should be "Make it work like the message window currently does.".

Thanks,
Blake.

Comment 6

[David :Bienvenu]

I can tell you from personal experience that people expect navigation to work in the stand-alone message window and by extension, the single message tab. I think you're wearing your developer hat when you're surprised that it works - the users I've worked with are not surprised, except when it's broken :-)

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

If we're going to support these features, we should probably do a pass on adding them to the documentation since they are neat.  Specifically, http://en.flossmanuals.net/thunderbird/ does not seem to know about the key.  https://support.mozillamessaging.com/en-US/kb/keyboard-shortcuts does, but it's just a giant list of stuff without context, so I think discovery is probably left to those who poke at the menus or belong to a thunderbird support group.

Also, I just realized that I'm definitely not the module owner for whatever this is, Jim is.  So he can decide how many mozmill tests he wants to write for this!  However, my personal opinion is punishingly many, so you might want to direct the next review request to someone who won't require that you go mad from mozmill test writing.  (The permutations make my head hurt, but if I can see that the mozmill tests take care of it, then my head doesn't hurt.)