Support for accessing menus by comparing with label attribute too

VERIFIED DUPLICATE of bug 92491

Status

()

Core
XUL
P3
normal
VERIFIED DUPLICATE of bug 92491
18 years ago
10 years ago

People

(Reporter: janv, Assigned: janv)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

18 years ago
This bug arised from discussion in bug 67731.
(Assignee)

Comment 1

18 years ago
adding people to CC list
(Assignee)

Comment 2

17 years ago
Here is my suggested behavior:
1. Acceskey has top priority.
2. If we found only one menu, then we select it and enter it.
3. If we found multiple menus, then we select only first one.
4. User can type next letters to precise his search criteria

I'll attach initial patch.
Summary: Support for accessing menuitems with first letter → Support for accessing menus by comparing with label attribute too
(Assignee)

Comment 3

17 years ago
Created attachment 43939 [details] [diff] [review]
initial fix

Comment 4

17 years ago
Windows handles duplicate menu access keys, which default to the first 
character if one isn't explicitly defined, differently than what you propose.  
If there are two or more menu items with the same access key, pressing the key 
repeatedly will cycle through the menu items.  There is no incremental search.
(Assignee)

Comment 5

17 years ago
ok, but do we want windows behavior ?
I prefer incremental search.

Comment 6

17 years ago
I appreciate the work that went into implementing it, although I'm not sure how
necessary incremental search really is.  I think most users would just find the
item they're looking for when it gets to the point that they have to type out
half the word...

Comment 7

17 years ago
incremental search is useful for lists, but for menus i'd rather follow the 
windows behavior.

If you want to implement a useful menu access feature there's the BeOS behavior 
which dynamically assigns access keys to menu items based on a first avaailable 
algorithm. (i think that's probably filed as some other bug... i don't know 
offhand).

Comment 8

17 years ago
Good point.  Rather than working around a lack of access keys, it would probably
be better to determine a way of automatically assigning an access key if one
isn't assigned.
(Assignee)

Comment 9

17 years ago
Ok, it sounds good.

Let's sumarize it:
1. We will dynamically assign access keys to menu items based on a first
   available algorithm. This can be suppressed by setting "noautoaccesskeys"
   attribute ?
2. Menulists will use incremental search.
(Assignee)

Comment 10

17 years ago
Hmm, it would be probably better to not enable auto access keys by default.

Comment 11

17 years ago
*** Bug 42858 has been marked as a duplicate of this bug. ***

Comment 12

17 years ago
*** Bug 105201 has been marked as a duplicate of this bug. ***
*** Bug 110587 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

16 years ago
Priority: -- → P3
Target Milestone: --- → Future
(Assignee)

Comment 14

16 years ago

*** This bug has been marked as a duplicate of 92491 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 15

16 years ago
v
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.