Closed Bug 304676 Opened 19 years ago Closed 14 years ago

Right clicking a message or clicking the twisty focuses topmost visible item (message) when tree has no initial focus

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: ispiked, Unassigned)

References

Details

(Keywords: helpwanted, regression) 

1. Open up a new folder that you haven't looked at.
2. Right click on a message or click on a twisty if it's a thread.

You will see that the topmost message got focus (when you right click you see
the message highlighted, but it's not focused).

Regresssion from patch on bug 280153. See bug 302516 comment 13 for further info.
Focus does not go to a message, it goes to the tree.  The dashed line 
surrounding an item is the "current" indicator, and is not shown when the tree 
does not have focus.  The reversed-color display of one or messages is the 
"selection," and the background color is shown lighter if the tree does not have 
focus.

In 1.0.x, a folder that has not had a message selected yet has the "current" 
position unset.  With the focus on a folder, if you
  1) click on a twisty, there is no visible change in current or selection;
  2) right-click on a message when there is no visible current or selection, the 
item you clicked on is highlighted while the menu is displayed; once the menu is 
no longer displayed, the tree reverts to no visible current or selection.  

In both cases, the focus has shifted from the folder pane to the thread pane.  
If you type a down-arrow, the current (and the selection) is set to the topmost 
item in the thread pane, which will scroll back to the top if necessary.

In current trunk builds (since bug 280153 was fixed), a folder that has not had 
a message selected yet has its "current" set to the topmost visible item in the 
tree.  With the focus on the folder pane, if you:
1) click a twisty, the "current" is now made visible (because thread pane now 
has focus), but does not move.
2) right-click on a message, then clear the menu, the "current" is both made 
visible and highlighted as a selection.  *However*, the selected item is not 
loaded in the preview pane.

Again, the focus shifts in both cases; the difference is where the "current" is 
and, in the right-click case, what happens to the selection.

Having the "current" indicator show focus is consistent with Windows.  
Behavior 1 (twisty-clicking) is consistent with Windows (e.g. Outlook Express).
I don't think TB is buggy in this instance.

But right-clicking an item (behavior 2) in Windows moves the selection to that 
item -- *if* the item is in a "listbox" control, which is used for the Windows 
Explorer folder-contents list and the Outlook Express analog to the message 
pane.  Right-clicking on an item in a Windows "tree" control (Explorer's and 
OE's folder lists) does *not* move the current or selection (except while the 
context menu is displayed).

Right-clicking an unselected message in Outlook Express moves the selection 
*and* immediately loads the selected message in the preview pane.

(I don't mean to imply that Windows is the ultimate arbiter of UI behavior, but 
it's what I've got to work with, and it *is* in fact pretty well thought out.)

In Firefox 1.0.6, right-clicking an unselected item in the bookmark manager does 
move the selection.  (I don't have a current trunk build of Fx handy to test 
with.)

I think TB's current behavior is at least partly a good thing.  I like being 
able to right-click on a single message without having that message immediately 
loaded in the message pane -- for instance, if I'm about to delete something 
that looks like spam.  

However, if the "current" is going to remain where it is, then after the context 
menu closes, TB should either not select the "current" item, or select the 
"current" item *and* load it into the message pane.
Severity: normal → minor
The behavior I think would be ideal is somewhat complex, and might well fail the 
User Experience Laboratory test.  I would like that when the right-click occurs 
outside of a selection, the clicked item be highlighted; the "current" indicator 
be shown wherever it currently is (if within the scroll region); and any 
existing selection (single or multi) be continued to be shown as a selection, 
but with the lighter "unfocused" background color.

Then, after the menu has been cleared: if the item no longer exists in the tree, 
revert the selection and "current" to what they were before; if the item still 
exists in the tree, revert the selection but move the "current" to the clicked 
item.  The "current" item could then be added to the selection with ctrl-click 
(or ctrl-space, once bug 238834 is fixed), or selected (and loaded into the 
preview pane) with click or space.

A right-click *within* a selection (specifically, within a multi-selection) 
should move the "current" indicator to the clicked item while maintaining the 
selection -- and of course, the context menu here applies to the selection, not 
the single item.
Somewhat OT (sorry!) -- adding more extensive logic for setting "current" 
instead of selection would help some other bugs, in particular the one where an 
item (potentially junk) is selected and loaded after <Delete Mail Marked as Junk 
in Folder>.
To the discussion in comment 1, I'd like to add the following:
Clicking in the Read, Flag or Junk column changes the corresponding state of the 
message.  In 1.0, clicking one of those items was analogous to clicking on the 
twisty: the focus would shift to the thread pane, but with no selection or 
current already in place, none would occur.

In 1.5, clicking in the Read or Flag column is still analogous to clicking the 
twisty: the action is taken, the focus is shifted, the 'current' (now always 
set) becomes visible, but does not move; nor is a selection created.  The same 
occurs if you click in the Junk column to *clear* the junk state, or to set the 
state when configured not to move manually-junked messages.

However, clicking the Junk column to *set* the junk state, and you're configured 
to automatically move the junked message to the junk folder, the behavior is 
more like the right-click action: the 'current' becomes selected after the 
junked message is moved.  (xref bug 209748: the 'current' in some cases will 
advance by one message before getting selected.)  Unlike the right-click case, 
the selected message is loaded as well.

Per bug 209748, having a message loaded that the user didn't explicitly select 
is a problem since that message could be spam that the user doesn't want to see.
This brings me back to the behavior suggested in comment 2 -- for a non-
selecting action, the selection state should be maintained -- not only for 
right-clicks but for junk-column clicks.
I'm not following this discussion; is this a bug, or not? Is it related to the fact that TB after 1.0.x, whenever you marke a message as junk, it's then marked as read and the following message is focused -- or not? Should I enter a new bug for the latter, or not? 

This is definitely a new bug, and a new behavior. I'm unclear after this discussion on why that should be unclear. Whether or not it matches someone's mental model of how it ought to work, it's different from how it did work, and sufficiently so that it is quite annoying. Aside from the potential exposure to spam and malware, it messes with my ad hoc tracking of spam -- I used to be able to tell how much i was getting by looking at the "unread messages" number on my junk folder, and now I have to mark all as unread before I can tell. I know it sounds picky, but it's an example. 
Comment 6 is about behavior unrelated to this bug; see bug 209748 comment 28.
*** Bug 331896 has been marked as a duplicate of this bug. ***
Aaron wrote to me:
[[
I'm pretty swamped and am not sure when I can get to it.
]]

'helpwanted' then.
Blocks: 282183
Keywords: helpwanted
Blocks: 282190
The behavior described in comment 5 no longer manifests -- I think because of the fix at bug 209748.  This is good!

Adam, you never responded to my (admittedly lengthy, and partially off-topic) comments.  Per comment 1, I think this bug should be resummarized for the issue of right-click causing a visible selection without actually loading the message.  What do you think?

(Comment 2 requires a new bug.)
QA Contact: front-end
This is marked dependent of syncing xpfe and toolkit listbox.xml, but both Thunderbird and SeaMonkey are using toolkit's version now. Is there anthing still needed to do here?
If yes, can dependencies, etc. be corrected for the real issue(s)?
(In reply to comment #11)
>If yes, can dependencies, etc. be corrected for the real issue(s)?
This bug is already marked as blocking bug 280153 which caused the regression.
Keywords: regression
accessibility issue?
Severity: minor → normal
Anyone still see this?

comment 1 WFM version 3.0a1pre (2008050103) - no focus of topmost message as far as I can tell (or perhaps I misunderstand the symptoms)
steps which show the problem (from Neil)
1) create a new folder 2) copy two new messages into it 3) select the folder 4) right-click the second message 5) press escape
I realize that my comments 1 thru 5 did carry on a bit, but I didn't think they were that obtuse.  I do still see the same right-click behavior that I described.  I was trying to explain what was happening and to convince Adam that the twisty-click case, at least, is not a bug.  (It *was* a deliberate change in behavior w.r.t 1.0.) 


Following the steps-to-reproduce in comment 15:

Actual results:
Topmost message in thread pane is highlighted as if selected (but message is not loaded in the message pane).

Expected results:
No highlight, just a "current" rectangle.

Desired results:
See comment 2.  :)
Incidentally, also referring back to my #2, I discovered today that Outlook 2007 does nearly as I described there: a right-click puts the "current" indicator on the clicked item, but maintains the selection as it was before; when the menu is cleared, "current" returns to its previous location.  This would be excellent behavior to mimic.
(In reply to comment #16)
> Desired results:
Personally following those steps I'd prefer there to be no selection at all.
Yes, I agree; in fact, comment 2 doesn't directly address the steps in 
comment 15, I posted without checking.  I think preserving an existing selection when right-clicking elsewhere is a reasonable behavior, tho.
aaronleventhal do  you still want assignee?
No
Assignee: aaronleventhal → nobody
I've taken a look at the behavior in this bug in the trunk (Lanikai 0410).  Understanding it is now a little more difficult thanks to bug 558578.


(In reply to comment #1)
> In current trunk builds (since bug 280153 was fixed), a folder that has not 
> had a message selected yet has its "current" set to the topmost visible item 
> in the tree.  With the focus on the folder pane, if you:
> 1) click a twisty, the "current" is now made visible (because thread pane now 
> has focus), but does not move.

Still true

> 2) right-click on a message, then clear the menu, the "current" is both made 
> visible and highlighted as a selection.

No longer true; item is not highlighted, but current is visible.  This is consistent with (1) and a good thing.



> In Firefox 1.0.6, right-clicking an unselected item in the bookmark manager 
> does move the selection.

Still true in 3.6.3; I don't have a trunk build.


> I think TB's current behavior is at least partly a good thing.  I like being 
> able to right-click on a single message without having that message
> immediately loaded in the message pane -- for instance, if I'm about to
> delete something that looks like spam.

I still think this is true.  In fact, I'm revisiting this bug because I'm working on determing the cases where items are getting selected and loaded when I don't think they should.


> However, if the "current" is going to remain where it is, then after the 
> context menu closes, TB should either not select the "current" item, or 
> select the "current" item *and* load it into the message pane.

And now it does, in fact, not select the current item.  Yay.  This addresses Neil's comment 18.


The main point of my comment 1, perhaps lost in the verbage, is that the change from bug 280153 resulted in "current" always being set, instead of NO current set (and so no dotted rectangled displayed on focus) as in earlier versions.  I don't think that change was a bug; and the non-selection now seen in TB 3.x is the desired behavior.  So   =>  WFM
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Actually what I see in SeaMonkey is that right-clicking a message does cause the topmost visible item to become selected but at least it doesn't load. This change in behaviour landed as part of bug 460960 on the SeaMonkey side.
So at the time of comment 18, TB exhibited the non-loading select and SM did not, but now TB does not and SM does?  Peculiar.  TB didn't have the tabbed interface at that point, so it's not specific to the tabs.
At the time of comment #18 I think SeaMonkey exhibited the loading select (this was a regression from the switch to toolkit; SeaMonkey 1.x did not select). However SeaMonkey's tabbed mail is based on an old version of Thunderbird's tabbed mail so that might explain any differences in current behaviour.
(In reply to comment #23)
> Actually what I see in SeaMonkey is that right-clicking a message does cause
> the topmost visible item to become selected but at least it doesn't load. This
> change in behaviour landed as part of bug 460960 on the SeaMonkey side.
Strangely it didn't work today. I wonder what's different.
You need to log in before you can comment on or make changes to this bug.