68243 - add mnemonics to all prefs panels

Status: RESOLVED WONTFIX

(SeaMonkey :: Preferences, defect)

Description

[Jesse Ruderman]

german said in bug 18575 that he was working on a spec listing the accesskeys 
for the various prefs panels.  (Btw, should the "Category" pane get an 
accesskey that is active no matter which pane is selected?)

Making the accesskeys actually *work* after they're added depends on bug 959 
and maybe bug 64150.

Comment 1

[sairuh (rarely reading bugmail)]

methinks this should live in either the prefs or keybd nav component [easier to
search for me]. i'll keep it assigned to german, tho', since he's writing up the
spec for it. if anyone really wants this back in ui/df, pls do keep me on the cc
list. thx!

dependency confusion: wouldn't 40759 actually be dependent on this one?

Comment 2

[Matthew T (active 1999-2002)]

> should the "Category" pane get an accesskey that is active no matter which pane
> is selected?

No, it should be accessed using Control+Tab.

> wouldn't 40759 actually be dependent on this one?

Nope. Bug 40759 must be fixed before this bug can properly be marked fixed.

Comment 3

[Samir Gehani]

Over to Marlon.  

Comment 4

[marlon bishop]

i think this belongs in aaron's domain.  not sure what spec german was working
on.  aaron?

Comment 5

[Aaron Leventhal]

Once 959 is marked fixed, I'm going to farm these out - there are a lot of them.

Comment 6

[Aaron Leventhal]

I'll take it.

Comment 7

[zhang]

hi,this is a test!

Comment 8

[zhang]

hi,this is a test!

Comment 9

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 11

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 16

[Edmund Wong (:ewong)]

Is this bug still valid for the current trunk?  

Unless I misunderstood this bug, for the following build:

Build identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b12pre) Gecko/20110218 Firefox/4.0b12pre SeaMonkey/2.1b3pre,  

this is WORKSFORME.

Comment 17

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 SeaMonkey/2.7a1 ID:20111017003001

The prefs dialog has been completely rewritten as part of the Toolkit Transition for SeaMonkey 2.

All panes & widgets are now in taborder, accesskeys exist on the right pane, so that part is WFM.

Categories still have no accesskeys but they can be selected by ← ↓ ↑ → so I suppose adding accesskeys to specific categories is WONTFIX. IanN?

Comment 18

[Tony Mechelynck [:tonymec]]

WONTFIX for the remaining part as per IanN over IRC.

Comment 19

[Ian Neal]

We won't fix categories with the current tree design.