Closed
Bug 280153
Opened 20 years ago
Closed 19 years ago
Often no visible focus when tabbing to tree
Categories
(Firefox :: Keyboard Navigation, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: aaronlev, Assigned: aaronlev)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(2 files)
(deleted),
patch
|
mconnor
:
review+
mconnor
:
approval1.8b4+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
mconnor
:
review+
benjamin
:
approval1.8b4+
|
Details | Diff | Splinter Review |
To repro: Alt+B to open bookmarks Alt+S to focus search Tab What happens: Focus is in the tree view which lists the bookmarks, but is not visible. How to fix: When a tree gets focused, and no item is selected yet, select the first item. The selection highlight shows focus and makes it obvious that arrow keys will move around. This will also help screen readers, which are confused by focused a tree/list with no item selected.
Assignee | ||
Updated•20 years ago
|
OS: Windows XP → All
Priority: -- → P3
Assignee | ||
Comment 1•20 years ago
|
||
Scott, could you take a look and tell me if this is out of the question for TBird? We did this in Photon and it worked out fine. It's nice when the user tabs to the mail to have a visible position. I'm not aware of other apps that don't show selection in a list when you tab into them.
Comment 2•20 years ago
|
||
Unless I'm misunderstanding what you're saying, Aaron, the reason we don't select a message in the thread pane by default is that we should not be reading a message for the user w/o his/her say so. Selecting a message causes the message to be marked read, and loaded in the message area. If we were to select an item but not load the corresponding message, or mark it read, that would be inconsistent. That being said, perhaps we could have an option for this. The other variable is that you can have tbird load the last selected message on a per-folder basis, but this isn't remembered across thunderbird sessions, and sometimes the last selected message is no longer present.
Assignee | ||
Comment 3•20 years ago
|
||
You're right, we shouldn't read a message and mark it read unless the user explicitly wants that. One thing that is very cool is that we don't automatically mark the message read if the message preview pane is not visible. In a previous project I worked on, we defaulted to no preview pane when a screen reader was present. That helped blind users quite a bit. (Slightly offtopic, I noticed that Tools -> Delete spam often automatically sends me to an unread message and marks it read, which I find annoyting.) I think we have several options: 1. Have a autoselect="false" attribute for outline, which would be used in the message pane and would disable this. In this case we need to develop a way for an outline to show focus when no item is selected. 2. Have an option for this, but I think that we should try to avoid that. 3. Just accept that when a keyboard user is tabbing into the mail messages (and there was no previously selected message remembed) that it is more confusing if they don't see focus, than if one of the messages is automatically selected, shown, and marked read. 4. Accept the inconsistency by not marking automatically selected messages read automatically. Since this is only an issue for keyboard users, I think it's not a heavy price to pay. It's easy to hit m or down/up to mark it read.
Comment 4•20 years ago
|
||
On Mac OS this shouldn't be a problem, because native listboxes/trees have an aqua/graphite border around them (or, if there isn't space around them, inside them) when focused, just like text fields do. On Windows this shouldn't be a problem either, because native listboxes/ trees have a state where an item has a dotted outline (and is therefore a starting point for arrow-key selection) but is not actually selected. If either of the above isn't emulated by the XUL control, fix that bug.
Assignee | ||
Comment 5•19 years ago
|
||
(In reply to comment #4) > On Mac OS this shouldn't be a problem, because native listboxes/trees have > an aqua/graphite border around them (or, if there isn't space around them, > inside them) when focused, just like text fields do. Agreed. Although at this point are there any keys other than down arrow which will initiate selection? > On Windows this shouldn't be a problem either, because native listboxes/ > trees have a state where an item has a dotted outline (and is therefore a > starting point for arrow-key selection) but is not actually selected. They have this state if they are multi select widgets. What about single select widgets? What does Gnome do in this situation?
Assignee | ||
Comment 6•19 years ago
|
||
Assignee | ||
Updated•19 years ago
|
Attachment #190188 -
Flags: review?(mconnor)
Updated•19 years ago
|
Attachment #190188 -
Flags: review?(mconnor)
Attachment #190188 -
Flags: review+
Attachment #190188 -
Flags: approval1.8b4+
Assignee | ||
Comment 7•19 years ago
|
||
Checking in toolkit/content/widgets/listbox.xml; /cvsroot/mozilla/toolkit/content/widgets/listbox.xml,v <-- listbox.xml new revision: 1.14; previous revision: 1.13 done Checking in toolkit/content/widgets/tree.xml; /cvsroot/mozilla/toolkit/content/widgets/tree.xml,v <-- tree.xml new revision: 1.19; previous revision: 1.18 done
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 8•19 years ago
|
||
We are seeing this bug also within our IBMQA testing.
Comment 9•19 years ago
|
||
I believe this checkin caused the regression in bug 302516
Comment 10•19 years ago
|
||
In addition to causing the scrolling problem in Thunderbid, I'm wondering about the logic of this tree change. cc'ing mconnor too since he r/sr'ed and approved this for 1.8b4 in case he has thoughts. First off, I don't think focusing a tree widget should be selecting any element in the tree at all. That point aside, why would we assume that the very first item in a tree is the one to select if a tree widget receives focus? Whose to say the first tree item is even visible (which in our case it seldom is). The tree could be showing a view several pages down, we focus into the tree and now we move the view out from under the user to the very top of the tree. That seems really wrong from a usability point of view. If we do have to select something it should be something that is currently visible. But again, I'm not a fan of selecting anything here, I think that's a usability problem. Even if we did try to hack around this in all of the Thunderbird tree widgets, you could still have the same bug in Firefox where a tree isn't showing the very first row and we select it and move the scroll position on you. So they're going to have the same issue.
Assignee | ||
Comment 11•19 years ago
|
||
The code to select or focus a tree item only happens if there is no current item set. So it's easy -- you just set the currentItem/currentIndex right away when you create the create the tree view, so it doesn't have to guess. For multi select tree views we just focus the item, not select it. I'm fine for doing that for single selects too, if that makes a difference to you.
Assignee | ||
Updated•19 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 12•19 years ago
|
||
On a right click or a folder twisty click we probably should use that item for the focus, if there isn't a focus already. We could file a separate bug for those if we want to do them, but this patch eliminates the worst problem -- the unwanted scrolling.
Attachment #191722 -
Flags: review?(mconnor)
Updated•19 years ago
|
Attachment #191722 -
Flags: review?(mconnor) → review+
Assignee | ||
Comment 13•19 years ago
|
||
One other thing this changes is to not select the first item in a single select widget when we do this. In native widgets, a single select can have an item that is only focused, if you tab into it and nothing else has focus yet. Hitting space selects the item.
Assignee | ||
Updated•19 years ago
|
Attachment #191722 -
Flags: approval1.8b4?
Updated•19 years ago
|
Attachment #191722 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 14•19 years ago
|
||
Checking in toolkit/content/widgets/listbox.xml; /cvsroot/mozilla/toolkit/content/widgets/listbox.xml,v <-- listbox.xml new revision: 1.16; previous revision: 1.15 done Checking in toolkit/content/widgets/tree.xml; /cvsroot/mozilla/toolkit/content/widgets/tree.xml,v <-- tree.xml new revision: 1.21; previous revision: 1.20 done
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Comment 15•19 years ago
|
||
I'm not 100% keen on this fix, because (for the mailnews/TB thread pane) I liked not having a 'current' box (dashed line) before I'd picked a message. With the scrolling-prevention fix, I now have the 'current' at the topmost displayed item in a thread pane that's scrolled to the bottom (ascending sort by date) -- in practice, this is arbitrary. I'd rather see the 'current' initialized at the bottommost item, in ascending-sort case. Further: prior to this fix, if I right-click on a particular message, then cancel the menu (with <esc> or clicking elsewhere) the pane reverted to the previous state: no selection, no displayed 'current'. Now, if I cancel the menu, the 'current' item appears selected now (altho the message is not loaded into the message pane). So that's a tiny bit of regression. However, in a positive light, this fix appears to have resolved bug 185585, and mostly resolved bug 205666, at least in TB; I'm not seeing any improvement for either of these bugs with the 0806 Seamonkey. If a tree is empty, there is still no focus indication. Bug 230904 (which this bug originally duped) is now retargeted towards that specific issue. (In reply to comment #3) > (Slightly offtopic, I noticed that Tools -> Delete spam often automatically > sends me to an unread message and marks it read, which I find annoyting.) Aaron, that's bug 200138.
Assignee | ||
Comment 16•19 years ago
|
||
(In reply to comment #15) > I'd rather see the 'current' initialized at the > bottommost item, in ascending-sort case. This fix just creates a default behavior. We can change the default behavior to be smarter. Perhaps if there's a way for the tree view to know if it's sorted in reverse we could use the last visible line as the default currentItem. It's not hard at all for mail to set the default currentItem using its own logic, and then this code won't run at all. > Further: prior to this fix, if I right-click on a particular message, then > cancel the menu (with <esc> or clicking elsewhere) the pane reverted to the > previous state: no selection, no displayed 'current'. Now, if I cancel the > menu, the 'current' item appears selected now (altho the message is not loaded > into the message pane). So that's a tiny bit of regression. If I right click on a link in the browser, it focuses the link. When I hit escape, that link is still focused. I think we should do that -- and make right clicking on an item focus it. Any big reason not to? > If a tree is empty, there is still no focus indication. Bug 230904 (which this bug originally duped) is now retargeted towards that specific issue. Good, and I think we should try to fix that after the upcoming releases.
Comment 17•19 years ago
|
||
(In reply to comment #16) > It's not hard at all for mail to set the default currentItem using its own > logic, and then this code won't run at all. Is it possible to set currentItem to 'none'? > > Further: prior to this fix, if I right-click on a particular message, then > > cancel the menu (with <esc> or clicking elsewhere) the pane reverted to the > > previous state: no selection, no displayed 'current'. Now, if I cancel the > > menu, the 'current' item appears selected now (altho the message is not > > loaded into the message pane). So that's a tiny bit of regression. > > If I right click on a link in the browser, it focuses the link. When I hit > escape, that link is still focused. I think we should do that -- and make > right clicking on an item focus it. Any big reason not to? Hm. I had been thinking that, e.g., Windows doesn't shift focus in that case, but in fact it does. I think I confused this with the behavior when an item is already selected: right-clicking on another item, then cancelling, reverts the focus to the original item. Still, Mail behaves differently; however, I'll follow up the discussion in a Mail-specific bug, starting in bug 302516. Did this bug's patches make it into Seamonkey? The SM-0806 build isn't behaving quite as the TB-0806 does.
Assignee | ||
Comment 18•19 years ago
|
||
This was only done for toolkit, not for Seamonkey(xpfe).
Comment 19•19 years ago
|
||
(In reply to comment #4) >On Mac OS this shouldn't be a problem, because native listboxes/trees have >an aqua/graphite border around them (or, if there isn't space around them, >inside them) when focused, just like text fields do. > >On Windows this shouldn't be a problem either, because native listboxes/ >trees have a state where an item has a dotted outline (and is therefore a >starting point for arrow-key selection) but is not actually selected. Actually our trees already show the extra thick border when focused... but I would prefer to see a tree body frame outline fix rather than this JS hack.
Assignee | ||
Comment 20•19 years ago
|
||
(In reply to comment #19) > but I > would prefer to see a tree body frame outline fix rather than this JS hack. We're doing what native widgets on windows do now. We can fix the issues with right click and or clicking on twisties, etc.
Comment 21•19 years ago
|
||
(In reply to comment #18) > This was only done for toolkit, not for Seamonkey(xpfe). Aaron, Neil: I'm working on bug 282183, and wonder if there is a reason (for me) not to port/copy this to SM ?
Comment 22•19 years ago
|
||
(In reply to comment #21) >I'm working on bug 282183, >and wonder if there is a reason (for me) not to port/copy this to SM ? I'm waiting for all the issues alluded to in comment 20 to be fixed first. (In reply to comment #20) >We're doing what native widgets on windows do now. Not quite true, Windows simply initializes the currentIndex to 0 instead of -1.
Comment 23•19 years ago
|
||
(In reply to comment #22) > (In reply to comment #21) > >I'm working on bug 282183, > >and wonder if there is a reason (for me) not to port/copy this to SM ? > > I'm waiting for all the issues alluded to in comment 20 to be fixed first. See bug 304676.
Comment 25•5 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•