460648 - message header: Focus disappears when moving through collapsed list of many contacts e.g. in cc or to header (more-button, twisty, many addresses)

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Reader UI, defect)

Description

[Thomas D. (:thomas8)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3

When multiple email addresses within a given header (e.g. TO) are in collapsed state (twisty), moving focus indicator beyond the last visible contact of the collapsed header will make focus disappear as it iterates through all the invisible contacts. Strange visual effects, such as a dotted underline for the first contact (when focus is actually on the first contact of the second row which is hidden). It doesn't make sense and causes usability issues to have the focus on items that are currently hidden from user's view.


Reproducible: Always

Steps to Reproduce:
1. Message reader shows an email with some more recipients (so that list of recipients is collapsed by default)
2. Move focus to the last visible contact elements of first line of collapsed header, then press TAB again
3.
Actual Results:  
Focus iterates hidden contacts (second row of collapsed list)

Expected Results:  
Focus should not iterate hidden elements, but continue with next visible header

Comment 1

[Thomas D. (:thomas8)]

Things get worse when you actually do something on one of the hidden contacts. Set focus on first (hidden) contact of second row of collapsed headers, use context menu key on your keyboard to pop up context menu (second row contact scrolls into view, first row contacts now hidden), press ESC, then <shift>-tab to return focus to first row. First row is NOT scrolled back into view, and, which is worse, selecting another message and then returning to first message will not change the display, i.e. first row is not shown again unless you use twisty twice. Weird also that reply messages (same/similar id?) will have the same problem, i.d. first row will be hidden after a contact of second hidden row has had its context menu activated.

Comment 2

[Thomas D. (:thomas8)]

Additional suggestion for fixing this: Twisty for expanding collapsed headers should be focussable.

Comment 3

[Wayne Mery (:wsmwk)]

I am confirming, and not marking this a dupe of bug 458635 - but you may feel differently


(In reply to comment #2)
> Additional suggestion for fixing this: Twisty for expanding collapsed headers
> should be focussable.

this is a separate issue, which might already have been filed. but if you don't find it, please file a new bug

Comment 4

[Phil Ringnalda (:philor)]

I'm not sure about that expected result - I'm inclined to think that if I'm tabbing through contacts and I go past the last visible one, I'd expect the invisible ones to be unhidden, rather than skipped. I am sure, though, that tabbing through invisible things is very wrong.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

As per <http://weblogs.mozillazine.org/dmose/archives/2009/06/thunderbird_compact_header_mov.html>, the compact header is no longer part of the Thunderbird core, so this bug is no longer valid.

Comment 6

[Thomas D. (:thomas8)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090627 Shredder/3.0b3pre

Reopening. This bug is NOT reported against the compact header (where ALL of the header information is reduced to two lines), but against normal header view with many addresses e.g. in to or cc where the respective set of addresses is in "collapsed" state, i. e. there is a "more" button next the 3 addresses that are visible to show the rest of the addresses. This bug is still present in the current nightly. And I don't think TB devs will be suicidal enough to act on  Bug 499989 (current summary: Remove "more" indicator from mail header view) in a way that actually "removes" the collapsed state for many addresses in to or cc header for normal header view.

Comment 7

[Thomas D. (:thomas8)]

Corrected the summary that was incorrectly changed by Dan to include "compact message header" before he invalidated the bug. New summary of this bug is now

message header: Focus disappears when moving through collapsed list of many contacts e.g. in cc or to header (more-button, twisty, many addresses)

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

Good catch; sorry for the mistake!

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

As much as we'd love to see a fix for this, it affects a small enough percentage of users that we wouldn't actually block Tb3 on it if this were the last bug standing.

Comment 10

[Thomas D. (:thomas8)]

This bug was marked "blocking-thunderbird3+" by philringnalda in January 2009, so perhaps it deserves to be marked "blocking-thunderbird3.1+" so that we don't lose it for the next release. The current behaviour is quite embarassing, and makes people feel that TB has been designed in a sloppy way.

(In reply to comment #8)
> As much as we'd love to see a fix for this, it affects a small enough
> percentage of users that we wouldn't actually block Tb3 on it if this were
> the last bug standing.

I sometimes wonder where you guys get your data from. Unless there are large-scale field studies at hand, how can you tell that this bug affects "a small enough percentage of users"? It affects all keyboard users, including but not limited to people with accesibility problems. Even if only 10% of all TB users were affected (we really don't know, do we?), that would be how many tens or hundreds of thousands of users?

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #10)
> This bug was marked "blocking-thunderbird3+" by philringnalda in January 2009,
> so perhaps it deserves to be marked "blocking-thunderbird3.1+" so that we don't
> lose it for the next release.

Sounds reasonable; done.

> The current behaviour is quite embarassing, and makes people feel that TB
> has been designed in a sloppy way.

You're right that it's less than ideal, but it's very important for us not to let the perfect be the enemy of the good.

> (In reply to comment #8)
> > As much as we'd love to see a fix for this, it affects a small enough
> > percentage of users that we wouldn't actually block Tb3 on it if this were
> > the last bug standing.
> 
> I sometimes wonder where you guys get your data from. Unless there are
> large-scale field studies at hand, how can you tell that this bug affects "a
> small enough percentage of users"?

Quite right, there's no data behind this conclusion, it's based on my hunch.  I very much wish we had more data on which to base decisions like this, and Mozilla is pushing to see that happen over the long term (check out the Test Pilot), but that's not where we're at today.

> It affects all keyboard users, including but

I assume by "all keyboard users", you mean "all people who happen to use the keyboard to tab through the recipient lists".  I think (again, without supporting data), that this is a (relatively speaking), smaller group of people.

> not limited to people with accesibility problems. Even if only 10% of all TB
> users were affected (we really don't know, do we?), that would be how many
> tens or hundreds of thousands of users?

Indeed, it would be a non-trivial number.  That said, we've reached the point in the ship cycle where there's a very large amount of good work built up in the tree.  We need to ship; <http://ccgi.standard8.plus.com/blog/archives/242> has more details.

Comment 12

[Thomas D. (:thomas8)]

(In reply to comment #11)
Thanks Dan, that was helpful to understand your POV. We all look forward forward to the shipping of the existing goodies. Yet looking at the current state of the header pane, I sometimes worry that people might be detracted from the goodness by all the visual and functional flaws that might bite you at first sight. And then, you never get a second chance to make a first impression. Otherwise you're quite right, and rumour has it that "don't let the perfect be the enemy of the good" is wisdom that I might need to familiarize myself with occasionally ;)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090820 Shredder/3.1a1pre

This bug appears to have been fixed in current nightly. Current behaviour is now that <tab>ing through collapsed/hidden contacts will focus them and scroll them into view, one line each. This may not be the ideal behaviour yet, but it's working in terms of this bug --> worksforme.

In the longer run, along the lines of Phil Ringnalda's comment #4, consider expanding the collapsed list of contacts when user goes past the last visible one of the first row. Which might be worth a follow-up bug.

Comment 13

[Thomas D. (:thomas8)]

As per Phil's comment #4: Follow-up Bug 511745 (Header pane: Collapsed list of contacts should be expanded when user moves focus past the last visible contact using <tab>)

Comment 14

[Thomas D. (:thomas8)]

reopening, I spoke too fast.

unfortunately, some of the related behaviour mentioned in comment #1 is still there

Steps to reproduce:
1. message with multiple recipients, <tab> through collapsed list of to-recipients
-> when you go past last visible to-recipient of first row, second row is scrolled into view
2. now immediately click on another mail message

Actual behaviour:
- the other message also has the second row of to-recipient's scrolled into view. If there is just one recipient (single row), you will see NO recipients at all in the other message

Expected behaviour:
- viewing another message should always have the first row of recipients scrolled into view

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #12)
> (In reply to comment #11)
> Thanks Dan, that was helpful to understand your POV. We all look forward
> forward to the shipping of the existing goodies. Yet looking at the current
> state of the header pane, I sometimes worry that people might be detracted from
> the goodness by all the visual and functional flaws that might bite you at
> first sight. And then, you never get a second chance to make a first
> impression. 

Agreed; there's still a bunch of work to do on the header pane before we ship 3.0.  It's my belief that we can reach a state of "good" by fixing a set of bugs that doesn't happen to include this one.  That said, we won't know for sure until we're closer to that end state.

> In the longer run, along the lines of Phil Ringnalda's comment #4, consider
> expanding the collapsed list of contacts when user goes past the last visible
> one of the first row. Which might be worth a follow-up bug.

Agreed again; thanks for filing this bug.

(In reply to comment #14)
> reopening, I spoke too fast.

Since this behavior is somewhat different than that discussed in the rest of the bug, I've spun comment 14 off into bug 511915 and am reclosing this one.  The reasoning is that bug morphing tends to be bugs difficult and complicated to follow, especially for new folks joining in on the bug.