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>.
See also bug 264973 comment 4.
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.
*** 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.
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.)
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.
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?
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
Last Resolved: 9 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.