Closed
Bug 563912
Opened 14 years ago
Closed 13 years ago
Allow the tab key to only move to the items relevant to the selected extension
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
VERIFIED
FIXED
mozilla2.0b12
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: MarcoZ, Assigned: mossop)
References
Details
(Keywords: access, regression, Whiteboard: [rewrite][softblocker])
Attachments
(1 file, 1 obsolete file)
3.84 KB,
patch
|
Unfocused
:
review+
|
Details | Diff | Splinter Review |
STR: 1. Make sure you have two or more extensions installed. 2. In Add-Ons Manager, choose "Extensions" from the categories. 3. Tab to the list of extensions. For example if I have: Adblock Plus ChatZilla GreaseMonkey 4. Choose the second, ChatZilla. 5. Press Tab. Expected: Focus should move to "The ChatZilla Team". Actual: It moves to whoever created the very first extension. 6. Also, when tabbing, after going through all options of Adblock Plus and ChatZilla, the options for GreaseMonkey are also being tabbed through. With 10, 20, 30 or more extensions, this can become very cumbersome.
Reporter | ||
Comment 1•14 years ago
|
||
This is also true for the "Search Engines", "Plugins" etc. pages.
Reporter | ||
Comment 2•14 years ago
|
||
To be absolutely clear, this is a usability regression from the old Add-Ons manager in 3.6. In 3.6, tab would move from the list item to the buttons pertaining *only* to the selected item. So if I am at item 15, in 3.6.x, tab would not move to the buttons for item 1. In current add-ons manager, selecting item 15 in the list, then pressing Tab, will move to the buttons for item 1. So the buttons for the selected items are 30 or 45 presses of the TAB key away at least.
Keywords: regression
Reporter | ||
Updated•14 years ago
|
Whiteboard: [rewrite] → [rewrite][softblocker?]
Comment 3•14 years ago
|
||
Talked with Marco this morning about important access related issues. In his option it's the most important one. Asking for blocking to get it on the soft blockers list. Looks like it's a really annoying regression from 3.6 for our disabled users.
blocking2.0: --- → ?
Hardware: x86 → All
Assignee | ||
Updated•14 years ago
|
blocking2.0: ? → final+
Whiteboard: [rewrite][softblocker?] → [rewrite][softblocker]
Comment 4•14 years ago
|
||
So, uh, anyone got any idea how to fix this?
Assignee | ||
Comment 5•14 years ago
|
||
Neil might have some ideas, I wonder if this is related to the changes that were made to differentiate between focusing with the mouse and focusing with the keyboard
Comment 6•14 years ago
|
||
When a richlistbox is focused (I'm assuming that's what is being used here), tabbing will begin from that. nsFocusManager::DetermineElementToMoveFocus would need to be changed such that if navigating from a richlistbox, it starts from the selected item instead.
Assignee | ||
Comment 7•14 years ago
|
||
Ah, the reason this worked in 3.6 is that in 3.6 only the selected item had visible buttons.
Comment 8•14 years ago
|
||
In a more hackish way, you could also adjust the focusability of things in non-selected itms.
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → dtownsend
Assignee | ||
Comment 9•14 years ago
|
||
I likes me some hacks
Assignee | ||
Updated•14 years ago
|
Whiteboard: [rewrite][softblocker] → [rewrite][softblocker][has patch][waiting on try]
Assignee | ||
Comment 10•14 years ago
|
||
Test fails on linux :(
Whiteboard: [rewrite][softblocker][has patch][waiting on try] → [rewrite][softblocker][has patch]
Assignee | ||
Comment 11•14 years ago
|
||
Passes everywhere now
Attachment #507304 -
Attachment is obsolete: true
Attachment #507554 -
Flags: review?(bmcbride)
Assignee | ||
Updated•14 years ago
|
Whiteboard: [rewrite][softblocker][has patch] → [rewrite][softblocker][has patch][needs review Unfocused]
Comment 12•14 years ago
|
||
Comment on attachment 507554 [details] [diff] [review] patch rev 2 Delightfully hacky.
Attachment #507554 -
Flags: review?(bmcbride) → review+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [rewrite][softblocker][has patch][needs review Unfocused] → [rewrite][softblocker][has patch]
Assignee | ||
Comment 13•14 years ago
|
||
Landed: http://hg.mozilla.org/mozilla-central/rev/5e4632c4dd7c
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [rewrite][softblocker][has patch] → [rewrite][softblocker]
Target Milestone: --- → mozilla2.0b10
Assignee | ||
Comment 14•14 years ago
|
||
Backed out due to test failures
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 15•13 years ago
|
||
Friendly ping. This bug is still not fixed and is possibly THE most nasty keyboard nav issue we currently have in FX4, and users will view this as a productivity regression, esp now that there are so many more features in add-ons manager.
Assignee | ||
Comment 16•13 years ago
|
||
This bug isn't forgotten, I did some try runs yesterday to try to narrow down the cause of the test failures. The problem at the moment though is that it only fails on tinderbox not on my local machine which is making debugging the problem hard.
Assignee | ||
Comment 17•13 years ago
|
||
Results: TEST-INFO | Running test 6 TEST-INFO | Focused element: {"localName":"richlistbox","id":"addon-list","className":"list"} TEST-INFO | Expected element: {"localName":"richlistbox","id":"addon-list","className":"list"} TEST-PASS | Focus should have moved to the list TEST-INFO | Focused element: {"localName":"page","id":"addons-page","className":""} TEST-INFO | Expected element: {"localName":"button","id":"","className":"details button-link"} TEST-UNEXPECTED-FAIL | Focus should have moved to the more button - Got [object XULElement], expected [object XULElement] TEST-INFO | Focused element: {"localName":"input","id":"","className":"textbox-input"} TEST-INFO | Expected element: {"localName":"button","id":"","className":"addon-control disable"} TEST-UNEXPECTED-FAIL | Focus should have moved to the disable button - Got [object HTMLInputElement], expected [object XULElement] TEST-INFO | Focused element: {"localName":"richlistbox","id":"categories","className":""} TEST-INFO | Expected element: {"localName":"button","id":"","className":"addon-control remove"} TEST-UNEXPECTED-FAIL | Focus should have moved to the remove button - Got [object XULElement], expected [object XULElement] TEST-INFO | Focused element: {"localName":"richlistbox","id":"addon-list","className":"list"} TEST-UNEXPECTED-FAIL | Focus should be outside the list TEST-INFO | Focused element: {"localName":"richlistbox","id":"categories","className":""} TEST-INFO | Expected element: {"localName":"button","id":"","className":"addon-control remove"} TEST-UNEXPECTED-FAIL | Focus should have moved to the remove button - Got [object XULElement], expected [object XULElement] TEST-INFO | Focused element: {"localName":"page","id":"addons-page","className":""} TEST-INFO | Expected element: {"localName":"button","id":"","className":"details button-link"} TEST-UNEXPECTED-FAIL | Focus should have moved to the more button - Got [object XULElement], expected [object XULElement] TEST-INFO | Focused element: {"localName":"richlistbox","id":"addon-list","className":"list"} TEST-INFO | Expected element: {"localName":"richlistbox","id":"addon-list","className":"list"} TEST-PASS | Focus should have moved to the list TEST-INFO | Focused element: {"localName":"richlistbox","id":"categories","className":""} TEST-PASS | Focus should be outside the list TEST-INFO | Test 6 took 66ms
Assignee | ||
Comment 18•13 years ago
|
||
Relanded with a change to the test to stop paying attention to OSX full keyboard access setting, the tinderbox have it set so only textboxes and lists can get focus. http://hg.mozilla.org/mozilla-central/rev/c99cefaa4c8e
Status: REOPENED → RESOLVED
Closed: 14 years ago → 13 years ago
Resolution: --- → FIXED
Target Milestone: mozilla2.0b10 → mozilla2.0b12
Comment 19•13 years ago
|
||
Marco, if you have the time it would be great when you could verify the fix and if it now works better for you. Thanks.
Reporter | ||
Comment 20•13 years ago
|
||
This is verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre However, it introduced a new bug that now traps keyboard focus at some undefined place (on the outer frame) when initially opening the add-ons manager. You have to click somewhere with the mouse to untrap it. I will file a new bug for this.
Status: RESOLVED → VERIFIED
Comment 21•13 years ago
|
||
This softblocker caused two regressions (see dependent bugs) that are both nominated for blocking. I think it should be backed out until it's ready to land without breaking other stuff.
Yes, please. Mossop?
Assignee | ||
Comment 23•13 years ago
|
||
I believe it actually only caused one regression, and that one I can't reproduce for myself. Unless Marco still agrees that the other bug is worse than this I'm inclined to leave this in for now.
Assignee | ||
Comment 24•13 years ago
|
||
Now looks like this didn't cause any regressions so it stays in for now.
You need to log in
before you can comment on or make changes to this bug.
Description
•