Closed
Bug 67952
Opened 24 years ago
Closed 22 years ago
Support for accessing menus by comparing with label attribute too
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
Future
People
(Reporter: janv, Assigned: janv)
References
Details
Attachments
(1 file)
4.37 KB,
patch
|
Details | Diff | Splinter Review |
This bug arised from discussion in bug 67731.
Assignee | ||
Comment 1•24 years ago
|
||
adding people to CC list
Assignee | ||
Comment 2•23 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•23 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•23 years ago
|
||
ok, but do we want windows behavior ? I prefer incremental search.
Comment 6•23 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...
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).
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•23 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•23 years ago
|
||
Hmm, it would be probably better to not enable auto access keys by default.
Comment 11•23 years ago
|
||
*** Bug 42858 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
*** Bug 105201 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
*** Bug 110587 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Assignee | ||
Comment 14•22 years ago
|
||
*** This bug has been marked as a duplicate of 92491 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
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.
Description
•