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)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.8
People
(Reporter: jruderman, Assigned: ssu0262)
References
Details
(Keywords: access)
Attachments
(1 file, 3 obsolete files)
(deleted),
patch
|
racham
:
review+
sspitzer
:
superreview+
|
Details | Diff | Splinter Review |
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.
Comment 2•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
->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
Comment 4•24 years ago
|
||
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.
Reporter | ||
Comment 5•24 years ago
|
||
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.
Comment 6•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
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).
Comment 8•24 years ago
|
||
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.
Reporter | ||
Comment 9•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
I agree with nbaca, i like the 4.x implementation.
Comment 11•24 years ago
|
||
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?
Comment 12•24 years ago
|
||
Keep focus in the Thread pane unless user tabs/selects the message pane.
Comment 13•24 years ago
|
||
I agree.
Comment 14•24 years ago
|
||
wait, in 4.x, alt-up/alt-down moved around in the thread pane, and the arrow
keys moved the message pane...
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
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.
Comment 17•23 years ago
|
||
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?
Comment 18•23 years ago
|
||
this is intended behavior - because 99% of the time, when a folder is loaded,
you want the arrow keys to navigate the thread pane...
Comment 19•23 years ago
|
||
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.
Reporter | ||
Comment 20•23 years ago
|
||
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.
Comment 21•23 years ago
|
||
*** Bug 78818 has been marked as a duplicate of this bug. ***
Comment 22•23 years ago
|
||
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
Reporter | ||
Comment 23•23 years ago
|
||
Copying nsbeta1+, P3, and 0.9.3 milestone from dup.
Comment 24•23 years ago
|
||
Putterman uses status whiteboard for nsbeta1+ tracking... fixing for him. :)
Keywords: nsbeta1+
Whiteboard: [nsbeta1+]
Comment 25•23 years ago
|
||
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?
Comment 26•23 years ago
|
||
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?
Comment 27•23 years ago
|
||
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.
Reporter | ||
Comment 28•23 years ago
|
||
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.
Comment 29•23 years ago
|
||
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?
Comment 30•23 years ago
|
||
I support the last suggestion. Sounds more reasonable.
Comment 31•23 years ago
|
||
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
Comment 32•23 years ago
|
||
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.
Comment 33•23 years ago
|
||
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.
Comment 34•23 years ago
|
||
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.
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
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.
Comment 37•23 years ago
|
||
>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.
Comment 38•23 years ago
|
||
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.
Comment 39•23 years ago
|
||
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?
Comment 40•23 years ago
|
||
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?
Reporter | ||
Comment 41•23 years ago
|
||
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?
Comment 42•23 years ago
|
||
I agree with putterman's comments on 2001-07-02 22:25.
Comment 43•23 years ago
|
||
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
Comment 44•23 years ago
|
||
not going to happen on the nsBranch, but on my list for 0.9.3
Comment 45•23 years ago
|
||
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...
Comment 46•23 years ago
|
||
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.
Comment 47•23 years ago
|
||
*** Bug 92108 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Keywords: nsBranch,
nsenterprise
Comment 50•23 years ago
|
||
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.
Comment 52•23 years ago
|
||
not a stopper for eMojo. triaging for the next release.
Comment 53•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Updated•23 years ago
|
QA Contact: nbaca → olgam
Updated•23 years ago
|
Priority: P2 → P1
Comment 56•23 years ago
|
||
I am glad that I found confirmation to my thoughts in comments #35 (Default
Focus) and #39 (common user behavior).
Comment 57•23 years ago
|
||
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
Comment 58•23 years ago
|
||
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?
Comment 59•23 years ago
|
||
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.
Comment 60•23 years ago
|
||
filed bug 112771.
yeah, the recent change in focus behavior is rather odd. anyone have any ideas
as to why?
Assignee | ||
Comment 61•23 years ago
|
||
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
Assignee | ||
Comment 62•23 years ago
|
||
Assignee | ||
Comment 63•23 years ago
|
||
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 64•23 years ago
|
||
Comment on attachment 60271 [details] [diff] [review]
patch 1.0
r=varada
Attachment #60271 -
Flags: review+
Comment 65•23 years ago
|
||
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.
Comment 66•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Comment 67•23 years ago
|
||
IMO, the patch do the right job.
Comment 68•23 years ago
|
||
The patch fixes the problem - why isn't it checked in yet?
Comment 69•23 years ago
|
||
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?
Assignee | ||
Comment 70•23 years ago
|
||
#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.
Comment 71•23 years ago
|
||
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.
Comment 72•23 years ago
|
||
I agree with putterman, comment #71, #39.
Comment 73•23 years ago
|
||
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.
Assignee | ||
Comment 74•23 years ago
|
||
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
Comment 75•23 years ago
|
||
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.
Assignee | ||
Comment 76•23 years ago
|
||
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
Comment 77•23 years ago
|
||
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.
Assignee | ||
Comment 78•23 years ago
|
||
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.
Comment 79•23 years ago
|
||
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.
Assignee | ||
Comment 80•23 years ago
|
||
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.
Comment 81•23 years ago
|
||
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'.
Assignee | ||
Comment 82•23 years ago
|
||
yes. the ' ' key still works as expected with the patch.
Comment 83•23 years ago
|
||
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.
Assignee | ||
Comment 84•23 years ago
|
||
Attachment #65137 -
Attachment is obsolete: true
Comment 85•23 years ago
|
||
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();
}
Assignee | ||
Comment 86•23 years ago
|
||
Updated•23 years ago
|
Attachment #65316 -
Attachment is obsolete: true
Comment 87•23 years ago
|
||
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+
Attachment #65325 -
Flags: review+
Comment 88•23 years ago
|
||
r=bhuvan
Assignee | ||
Comment 90•23 years ago
|
||
patch checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 91•23 years ago
|
||
*** Bug 120801 has been marked as a duplicate of this bug. ***
Comment 92•23 years ago
|
||
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!
Comment 93•23 years ago
|
||
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
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•