Allow the tab key to only move to the items relevant to the selected extension

VERIFIED FIXED in mozilla2.0b12

Status

()

Toolkit
Add-ons Manager
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: MarcoZ, Assigned: mossop)

Tracking

(Blocks: 1 bug, {access, regression})

Trunk
mozilla2.0b12
access, regression
Points:
---
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [rewrite][softblocker])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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

7 years ago
This is also true for the "Search Engines", "Plugins" etc. pages.
(Reporter)

Comment 2

7 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

7 years ago
Whiteboard: [rewrite] → [rewrite][softblocker?]
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

7 years ago
blocking2.0: ? → final+
Whiteboard: [rewrite][softblocker?] → [rewrite][softblocker]
So, uh, anyone got any idea how to fix this?
(Assignee)

Comment 5

7 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
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

7 years ago
Ah, the reason this worked in 3.6 is that in 3.6 only the selected item had visible buttons.
In a more hackish way, you could also adjust the focusability of things in non-selected itms.
(Assignee)

Updated

7 years ago
Assignee: nobody → dtownsend
(Assignee)

Comment 9

7 years ago
Created attachment 507304 [details] [diff] [review]
patch rev 1

I likes me some hacks
(Assignee)

Updated

7 years ago
Whiteboard: [rewrite][softblocker] → [rewrite][softblocker][has patch][waiting on try]
(Assignee)

Comment 10

7 years ago
Test fails on linux :(
Whiteboard: [rewrite][softblocker][has patch][waiting on try] → [rewrite][softblocker][has patch]
(Assignee)

Comment 11

7 years ago
Created attachment 507554 [details] [diff] [review]
patch rev 2

Passes everywhere now
Attachment #507304 - Attachment is obsolete: true
Attachment #507554 - Flags: review?(bmcbride)
(Assignee)

Updated

7 years ago
Whiteboard: [rewrite][softblocker][has patch] → [rewrite][softblocker][has patch][needs review Unfocused]
Comment on attachment 507554 [details] [diff] [review]
patch rev 2

Delightfully hacky.
Attachment #507554 - Flags: review?(bmcbride) → review+
(Assignee)

Updated

7 years ago
Whiteboard: [rewrite][softblocker][has patch][needs review Unfocused] → [rewrite][softblocker][has patch]
(Assignee)

Comment 13

7 years ago
Landed: http://hg.mozilla.org/mozilla-central/rev/5e4632c4dd7c
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Whiteboard: [rewrite][softblocker][has patch] → [rewrite][softblocker]
Target Milestone: --- → mozilla2.0b10
(Assignee)

Comment 14

7 years ago
Backed out due to test failures
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 15

7 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

7 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

7 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

7 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
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: mozilla2.0b10 → mozilla2.0b12
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.

Updated

6 years ago
Depends on: 633840
(Reporter)

Comment 20

6 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
(Reporter)

Updated

6 years ago
Depends on: 633899
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)

Updated

6 years ago
No longer depends on: 633840
(Assignee)

Comment 23

6 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)

Updated

6 years ago
No longer depends on: 633899
(Assignee)

Comment 24

6 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.