Closed Bug 70097 Opened 24 years ago Closed 23 years ago

pressing up/down in folder pane focuses thread pane

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.8

People

(Reporter: jruderman, Assigned: ssu0262)

References

Details

(Keywords: access)

Attachments

(1 file, 3 obsolete files)

Steps to reproduce: 1. Click on "inbox". 2. Press down. Result: thread pane now has focus. Expected result: message pane retains focus until I press tab. In bug 65667 there was some discussion about making it so that when you click on a folder, the thread pane becomes selected. I don't like that idea, because it means you would be clicking on one thing to focus another thing, and because it would make it awkward to actually get focus in the folder pane.
Cc mpt and aaron.
Keywords: access
Yes, we just noticed this the other days as well. There are a number of issues with this. There will probably be some keys that are used for "next folder" and "next unread folder" etc. In addition, some people have suggested that trees act as a list do - that is, you can type alphanumeric keystrokes and it moves the selection bar to the first tree item that starts with that combination of characters. Typing the same letter a number of times moves to the nth folder that starts with that letter. This is how it works in Windows, try it in Outlook Express.
->all since we've seen this on linux... but, to be sure: nbaca, have you seen this on mac? thx!
OS: Windows 98 → All
QA Contact: esther → nbaca
Hardware: PC → All
I think this will be XP. alecf added some code to switch focus to the thread pane after a folder loads. it's a nice feature for when the inbox gets selected automatically for you at startup. we'll have to think this one through.
How about just selecting the inbox and focusing the thread pane at startup? Then, after that, if the user clicks in the folder pane, leave the thread pane focused until the user clicks on the thread pane, presses tab or ctrl+tab, or uses one of the single-letter "next/prev message" keys.
actually, I was thinking of how extending the thread-pane thing to the message pane. how about when a message finishes loading, the focus goes to the message pane. then space would auto-scroll the message too.
That would solve the spacebar issue, but then you would have to tab back to the thread pane if you wanted to arrow up/down. (Not sure if that would bother people or not -- maybe people would like it better that arrows now scrolled the message.) Couldn't spacebar in the thread pane just be bound to "scroll the message in the message pane"? Seems like that would be an easier way of fixing the spacebar bug without having to shift focus (and then you wouldn't have to worry about spacebar maybe not scrolling after you clicked on the same header again).
I'm not sure about the default startup behavior but I basically like the 4.x implementation after messages have been selected in various folders. This is what I observed when using 4.x and an IMAP account: - At startup the Inbox is surrounded by a dotted line, with messages appearing in the thread pane and the Start Page displaying in the message pane. - If the Inbox folder is selected then it remains highlighted - If a message in the thread pane is selected then the header of the message remains highlighted and the contents of message is in the message pane - Switch to a second folder and only the folder is selected - Select a message in the thread pane and the header in the thread pane is selected while displaying its contents in the message pane - Switch to the Inbox folder and the Inbox folder is selected but the message in the thread pane is surrounded by a dotted line and the contents of the message are displayed in the message pane.
Making space scroll the message while the thread pane is focused is bug 33507. I don't think it would be a good idea to focus the message pane after clicking on a message -- that kind of thing often causes to the type of problem that led to this bug report.
I agree with nbaca, i like the 4.x implementation.
So the only open issue is whether we move focus from the thread pane to the message pane when a message is displayed? For key stroke users, the behavior then becomes: 1. Select Message in thread pane 2. Read message 3. Hit tab twice or shift+tab to move back to thread pane 4. Key Scroll Is this the behavior we want, or do we assume that folks want focus to remain in the thread pane?
Keep focus in the Thread pane unless user tabs/selects the message pane.
I agree.
wait, in 4.x, alt-up/alt-down moved around in the thread pane, and the arrow keys moved the message pane...
In 4.x windows the up and down arrow keys move up and down in the pane that currently has focus. For example, if the Thread pane has focus, the up/down arrows move up/down from message header to message header. If the Folder pane has focus, the up/down arrows move selected from folder to folder. Alt up/down seems to jump to the next *unread* message header, when the Thread pane has focus, the message pane has focus or the folder pane has focus.
In the absence of either bug 54171 or a useful Account Central page, there are only two ways to tell how many messages are present in each of your folders. The first, tiresome, way is to scrub the folder pane with the mouse, and wait for the tooltips to appear over each folder name. The second, easier, way is to focus the folder pane, then select each folder one by one (e.g. by using the arrow keys) and inspect its contents in the thread pane and status bar. For Mozilla to constantly push the user into the thread pane when they are trying to do this, making them press Shift+Tab (or Tab twice) to get back to the folder pane every time, is rather obnoxious. I can only think of one situation in the entire Mozilla suite where Mozilla should move focus from one visible element to another visible element, in the same window, without the consent of the user -- and this isn't it. Aaron's and Jennifer's comments are rather orthogonal to this bug. This is a focus issue, not a keyboard shortcut issue.
what mpt said. I switch between 4.x at home and 6.x at work (both win98se) and for some reason the folder counts don't get updated correctly when I switch back and forth. So I end up having to click in the folder pane, then use the arrow keys to go down over each folder to have it update the message count so I know what folders have unread messages in them. In 4.x this is easy, just click once, then down arrow over every folder. In 6.x this is a pain since I have to click on each folder because the focus goes back to the thread pane after every click. Very annoying, especially due to the speed of 6.x. Isn't this a 4x feature parity issue?
Keywords: 4xp
this is intended behavior - because 99% of the time, when a folder is loaded, you want the arrow keys to navigate the thread pane...
For mouse users it does make sense to say the majority of the time that the user will want the focus to be in the thread pane. For keyboard users I would prefer that the focus remain on the folder so the down/up arrow can move between folders and then let the user tab to the next pane if desired.
Mouse users usually don't care where focus is. Keyboard users often do, and they'll be annoyed if they can't figure out how to focus the folder pane with the mouse *and* with the keyboard.
*** Bug 78818 has been marked as a duplicate of this bug. ***
Marking nsbeta1 because I think it is important to fix, although I realize bug# 70097 is a dupe of this bug and was marked for 0.9.3.
Keywords: nsbeta1
Copying nsbeta1+, P3, and 0.9.3 milestone from dup.
Keywords: nsbeta1nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
Putterman uses status whiteboard for nsbeta1+ tracking... fixing for him. :)
Keywords: nsbeta1+
Whiteboard: [nsbeta1+]
Keywords: nsBranch
to satisfy both situations, perhaps we could do this: if the folder pane has focus, and the user hits "down", we'll only transfer focus to the thread pane after a certain number of micro seconds. that way, if the user hits down down down, we'll do the right thing. comments?
I think it would be great if we could avoid changing focus for someone just arrowing down. I don't know what the time is, but perhaps 1/2 a second before focus changes?
sspitzer's suggestion sounds good to me, but I would make it a large # of microseconds (on the order of 1000 ;-) because the only time I ever arrow down through the folders is to have mail open the folder and update the mesg count for the folder to check if there are any new messages in that folder. So the delay would have to be something like a second after the folder message count is updated.
I don't like the delay idea. The delay would have to be considerably longer than a second to allow me to see whether there's anything worth reading in the folder, but then the feature becomes less useful for mouse users because they have to wait before they can use arrow keys to scroll through the thread pane. Also, many users will wonder why focus moved to the thread pane (or why the black ring moved, if they're not familiar with the idea of focus) even though they haven't touched anything for over a second.
another idea, this might have already been suggested (and I'm not sure it is possible but...) if the user uses the mouse to select a folder (or if we automatically select the folder, for example the inbox on startup), we switch focus to the thread pane. if the user is using keys, we don't switch focus. (I figure if they are using keys, they don't want focus to jump on them.) comments?
I support the last suggestion. Sounds more reasonable.
or how about abstracting it out to any keyboard input - I'm imagining something where in onkeydown, you record some bit like "keyboard in use" state - then the folder changes, then you have an onkeyup event - the onselect event should happen in between
If we can detect key state vs. mouse click, then that sounds reasonable. I don't like the idea of a *delay* trying to presume what threshold is comfortable. The only expected behavior we can predict is keys vs. mouse - not the variables around perceived delay, speed of machine, etc.
I wouldn't care about this bug if I could trust seamonkey to accurately reflect the read/unread message status for each folder. When I switch between 4.x and 6.x I almost always find one or two folders that have unread messages but are not bold, which is why I end up going through all my incoming folders.
If Mozilla changes focus without the user's permission, it will look buggy. If Mozilla changes focus without the user's permission, after a delay, it will look slow *and* buggy. (It already has a delay, of about ten seconds!) If Mozilla changes focus or not depending on the input device, it will look inconsistent *and* slow and buggy. You're trying to be too clever here.
right now, clicking on another folder doesn't change the focus but using the up and down does. I'll work on fixing that first. clicking on "Read Messages" in account central loads the inbox and sets focus to the thread pane, I believe that is correct. on start up, if we are set to "check for new mail on startup", we select the inbox for the default account automatically and we set focus to the thread pane. I believe that is also the correct behavior.
it's actually the folderloaded event that focuses the thread pane.....on my build, when I click on a folder, there is a brief pause while the folder loads, then the focus arrives in the threadpane. I thought that we actually had a similar trick in the thread pane such that you could hit up/down in the thread pane to move between messages, and it wouldn't load the message until after a slight delay? by the way, I completely disagree with mpt that if we change the focus without the users permission, that it will look buggy. Matthew, I suggest you TRY to use the product with the thread pane not focusing automatically, and using the "N" key to go to the next message, I think you'll see how frustrating it can be.
>it's actually the folderloaded event that focuses the thread pane.....on my >build, when I click on a folder, there is a brief pause while the folder loads, >then the focus arrives in the threadpane. ah, that's what it does for me with IMAP, but not pop (local folders.) we must not be sending the folderloaded event for local folders. >I thought that we actually had a >similar trick in the thread pane such that you could hit up/down in the thread >pane to move between messages, and it wouldn't load the message until after a >slight delay? we do, some sort of timed select. >by the way, I completely disagree with mpt that if we change the focus without >the users permission, that it will look buggy. Matthew, I suggest you TRY to >use the product with the thread pane not focusing automatically, and using >the "N" key to go to the next message, I think you'll see how frustrating it >can be. if for 4.x if the folder pane had focus, "n" would switch to the thread pane go to the next unread message. the same should be possible in 6.x.
Ok, i just recently tried to use AIM's preference dialog. It's unusable because pressing the arrows results in focus switching to some stupid panel. otoh, icq's preference dialog, which will not win awards, doesn't do this, and is much better than aim's for this reason alone.
nbaca already mentioned what 4.x did. I tried Outlook Express and it also keeps focus on the folder pane. I thinke we should do the same. In current builds if you hit 'n' for next unread or 'f' for next message it moves the selection in the thread pane which is what we want. It doesn't currently cause focus to change. I'd rather have that cause the focus change than loading a folder. I think it's fine if the Inbox starts up with focus in the thread pane like 4.x but any folder that the user changes by mouse or keyboard should keep focus in the folder pane, in my opinion. I also think it's better to keep focus in the thread pane if the folder gets loaded due to Next Unread Message and Advance to next folder. But if the user selects the folder, I think it should keep focus. Right now it's very awkward to perform and folder operation. Alec, it looks like 'n' and 'f' work. What were your other concerns besides that?
I agree. Still allowing 'n' and 'f' operations although focus is in the Folder Pane seems right. However, scrolling using the arrow keys while in the folder pane: focus should remain since the user has clicked there (moved focus), but Next Unread and Next Message then are considered "thread pane operations" and moves focus to the thread pane. Is that not what we're driving at?
I think it makes sense for N/F to switch focus from the folder pane to the thread pane, but some of our users depend on it not switching focus from the *message* pane to the thread pane. Is it possible to make N/F switch focus to the thread pane only if the folder pane was focused before?
I agree with putterman's comments on 2001-07-02 22:25.
ok, when I get back to this I'll do what putterman suggested. besides n and f, we need to worry about space and any other key board command under the "Go" menu (next flagged, etc.)
Status: NEW → ASSIGNED
Keywords: nsBranch
Priority: P3 → P2
not going to happen on the nsBranch, but on my list for 0.9.3
under the Go menu there is: f for Next > Message n for Next > Unread Message t for Next > Unread Thread b for Previous > Message p for Previous > Unread Message do we care about m for Mark > Read/Unread under the Message menu? ie, any other single-key shortcut in other mailnews menus (if i'm missing others)? just curious...
Yes, all those keyboard shortcuts, and all shortcuts except those which for which focus changes their meaning (arrow keys, Page Up/Down, Delete), should do the same thing no matter what pane has focus.
*** Bug 92108 has been marked as a duplicate of this bug. ***
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Blocks: 92693
slide to 0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
I thought the Keywords nsBranch/nsenterprise meant that this bug should be fixed in 0.9.4. If this is sliding to 0.9.5 then should these keywords be removed or changed to include a minus? p.s. I would still like to see this fixed for this release, if possible.
Removing nsenterprise nomination.
Blocks: 99230
not a stopper for eMojo. triaging for the next release.
Keywords: nsbranchnsbranch-
Target Milestone: mozilla0.9.5 → mozilla0.9.6
No longer blocks: 99230
now I'm running into 95527 (message counts inaccurate), and have to click on every single folder I filter mail into every morning. It would make that bug much easier to take if I could click once in the folder pane and then down-arrow through each folder.
reassigning to ssu.
Assignee: sspitzer → ssu
Status: ASSIGNED → NEW
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
marking nsbeta1+
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Blocks: 107067
Keywords: nsbranch-
QA Contact: nbaca → olgam
Priority: P2 → P1
I am glad that I found confirmation to my thoughts in comments #35 (Default Focus) and #39 (common user behavior).
It looks like the findings shown in 112477 say that this is almost fixed. What's left is making sure that you can get out of the folder pane by some other means besides tab, such as 'n' or 'f'. Scott
re: comment 57: scott, that would be a good idea, using the single-letter shortcuts. currently, the single-letter shortcuts do display the appropriate message [eg, 'n' displays the first unread message in the selected folder, 'f' the first read/unread message, etc]. however, focus does remain in the folder pane, rather than switching to the thread pane. shall i file a separate issue for that?
sairuh, filing that bug would be great. I'm a little hesitant to mark this bug fixed until we somebody can say what caused the change in behavior in recent builds.
filed bug 112771. yeah, the recent change in focus behavior is rather odd. anyone have any ideas as to why?
this bug is still there in today's build. However, it only happens when you arrow down onto a folder that contains no messages. This happens for me under Win32.
Status: NEW → ASSIGNED
Attached patch patch 1.0 (obsolete) (deleted) — Splinter Review
This patch fixes the original problem of: arrowing up/down switches focus to the thread pane. It will no longer do this on any folder (empty or not).
Comment on attachment 60271 [details] [diff] [review] patch 1.0 r=varada
Attachment #60271 - Flags: review+
hold up, I don't think this is the right / complete fix. I need to read back in the bug history and see what jglick and others decided.
related to bug 65667/bug 112477: using a build from 12/10 now exhibits behavior of the thread pane gaining focus after a folder is selected [ie, when i mouseclick a folder, or arrow/up down to select a folder]. wonder why it reverted. odd.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
IMO, the patch do the right job.
The patch fixes the problem - why isn't it checked in yet?
I can't remember now why I wanted you to wait. Re-reading the bug, it looks like putterman and jglick agreed on this: 1) up / down arrows should not cause us to switch focus to the thread pane. 2) navigation (like 'n') should put the focus back on the thread pane after loading the next folder. 3) I think (based on http://bugzilla.mozilla.org/show_bug.cgi?id=70097#c39) putterman and jglick think that clicking on a folder should not throw the focus to the thread pane. does #2 still work with your patch? Can you check the code to make sure we do that for the other cross folder navigation commands? My one concern is that #3 is not correct. For example, on start up, when I have my prefs set to load my inbox, should focus be in the thread pane or the folder pane? (I bet it's cause of the existing code that we go to the thread pane.) Should we make it so on clicking (and on navigation commands) we want to shift focus, but on non-click we don't? When testing any fix, make sure to try news, local (pop) and imap (for clicking and for the "load my inbox at startup" scenario I described). I think that one (IMAP) might generate folder event that cause us to switch focus, where the others might not. (I vaguely remember this from some performance testing that cavin was doing.) jglick / putterman, can you confirm again what we want?
#2 actually is not working on the trunk right now. And my patch keeps it working as it is, which is to not put focus back on the threadpane when hitting either 'n' or 'f'. I actually agree with #3. It turns out that this patch makes #3 work that way. For your 'on startup' comment, I had asked Scott and Jennifer about it at one point because it was a seperate fix. Both like it to set the focus on the thread pane on startup, so I left it as is. I tried news, local (pop) and imap (for clicking and for the "load my inbox at startup" scenario you described): news, local (pop), and imap all no longer set focus to thread pane when arrowing up/down in folder pane or hitting 'n'/'f'. Clicking on folders also no longer set the focus on the thread pane (it used to). The threadpane focus on start up is not affected by this patch.
I still agree with #3. I think that the first time you start up it makes sense to put focus on the thread pane because that's not a user initiated action. But if the user moves to a folder, whether by keyboard or mouse, I think it should stay there. I do think we need to make "n", "f", and the arrow keys work when a folder is selected such that they bring focus to the thread pane and perform their specific action.
I agree with putterman, comment #71, #39.
I agree with putterman and jglick, comment #39, comment #71. It seems we are in a good shape. I check focus when navigate by "n", "f" or arrow keys from Mail default state. It works fine. If we all agree with discussed logic, I'll go through detail verification with each type of account.
Attached patch patch v1.1 (obsolete) (deleted) — Splinter Review
This new patch will: 1) leave focus on the folder pane when either clicking or arrowing to folders in the folder pane. 2) set the focus to the thread pane only if the focus is not on the message pane when hitting the following keys: 'n', 'f', 't', 'b', 'p', ' ' Meaning that if the focus is on the message pane, hitting the above keys will not set the focus to the thread pane.
Attachment #60271 - Attachment is obsolete: true
Sean, in 2) you say: 'set the focus to the Thread pane only if the focus is not on the message pane'. I believe, you also meant Not in Quick Search, nor Advanced button. So, expectation is to have focus in Thread pane with letter navigation in case of focused by default Inbox or having focus in Thread pane. Currently if focus is in the Message Body pane, clicking on 'n' moves focus to the next unread message in Thread pane.
I talked to Scott about this and got clearification that if the focus is currently on the Message Pane, then hitting the keys to navigate messages will not move the focus elsewhere. Focus will only be set to the Thread Pane if the focus is currently on any of the following panes when the navigation keys are used: Folder Pane Search Pane Search Button
If focus is on the Search field AND I click 'n' - it means that I do Search on 'n', but not looking for the next unread message. Focus should stay in Search.
You are absolutely correct. If the Search field has focus, and the nav keys are used, it will not move the focus away from this field. However, if the Advanced Search button has focus, then the focus will be changed to the Thread Pane.
If focus is on a button and a key is pressed the key should go to the button, or any related buttons. it should *not* go to some random field that's an uncle of the button.
Right now, the patch does not break the functionality of how the button gets triggered via the keyboard. There isn't a way to set an access key to the button and have it trigger the button.
ssu, with your last patch does ' ' still do the right thing in the message pane? if the message pane or thread pane has focus, space will do a page down in the message pane (for long messages), and once at the bottom, space will act like you hit 'n'.
yes. the ' ' key still works as expected with the patch.
instead of adding a call to SetFocusThreadPaneIfNotOnMessagePane() after (almost) every call to GoNextMessage(), why not add the call to SetFocusThreadPaneIfNotOnMessagePane() to the end of GoNextMessage()? note, you missed one call to GoNextMessage() case "cmd_killThread": /* kill thread kills the thread and then does a next unread */ GoNextMessage(nsMsgNavigationType.toggleThreadKilled, true); break; also, double check the white space on your final patch.
Attached patch patch v1.2 (obsolete) (deleted) — Splinter Review
Attachment #65137 - Attachment is obsolete: true
I'd suggest writing SetFocusThreadPaneIfNotOnMessagePane() in a way where you only call both GetXXX() if you have to. If you have a guess what has focus more of the time (thread pane or message pane), you could order them in a way to avoid the second GetXXX() call. for example, if you knew that the thread pane has focus more often that the message pane, you could do this: function SetFocusThreadPaneIfNotOnMessagePane() { var focusedElement = WhichPaneHasFocus(); if((focusedElement != GetThreadOutliner()) && (focusedElement != GetMessagePane())) SetFocusThreadPane(); }
Attached patch patch v1.3 (deleted) — Splinter Review
Comment on attachment 65325 [details] [diff] [review] patch v1.3 sr=sspitzer jglick, can you amend the spec to cover this behaviour?
Attachment #65325 - Flags: superreview+
Blocks: 112771
Attachment #65325 - Flags: review+
r=bhuvan
a=blizzard on behalf of drivers for 0.9.8
Keywords: mozilla0.9.8+
patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 120801 has been marked as a duplicate of this bug. ***
I think the focus should remain in the Folders pane in any case, this is the expected result in Windows and I find incongruent to move focus . it has a reason, too. just consider when consulting folders (i.e. to check titles): you must do it very fast to avoid the focus loosing action!
Verified on Linux, Win2K - with IMAP, POP, News - 01-29-2002 build. Partially on Mac OSX - can not get focus on Advanced button - the button skipped when navigate by Tab, or F6. Focus is set to the Thread Pane when the navigation keys are used - if the focus is currently on any of the following areas: Folder Pane - up/down arrows or letter navigation (both from default state and a Folder is intentially selected). Also letter navigation - when a Folder is intentially selected. Search Button - by using letter navigation: f, n, t, b, t, p. From Search field: Navigation arrows or letters do not move focus to Thread pane. Also I verified that if the focus is currently on the Message Pane, we can navigate messages by letters (f, n,) but focus do not move elsewhere.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: