Closed
Bug 81723
Opened 23 years ago
Closed 22 years ago
keyboard context menu (shift+f10) should open near focused item
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: deanis74, Assigned: aaronlev)
References
Details
(Keywords: access, helpwanted)
Attachments
(1 file)
Son of bug 74410... Now that that bug is fixed, it would be nice for the context menu to open close to the focused item when initiated by the keyboard. Currently the menu appears at 0,0.
Comment 1•23 years ago
|
||
eh. i just did what IE does.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 2•23 years ago
|
||
Does Mozilla have a way to find out where on the screen the focused element is? See also bug 12422, [Win32] Mozilla doesn't expose keyboard focus to screen-magnifier programs.
Summary: keyboard context menu should open close to focused item → keyboard context menu should open near focused item
pink, is this any easier with the new popup alignment xul syntax? http://www.mozilla.org/projects/xul/tests/popups.xul
Assignee | ||
Updated•23 years ago
|
Summary: keyboard context menu should open near focused item → keyboard context menu (shift+f10) should open near focused item
The context menu now appears at the current mouse position, which means that it for keyboard users it will never be at a standard position.
*** Bug 121087 has been marked as a duplicate of this bug. ***
Can we at least change it back for now to appearing at 0,0 of the content area, for some sort of consistency?
Updated•22 years ago
|
Keywords: helpwanted
Assignee | ||
Comment 8•22 years ago
|
||
There is an accessibility problem here. If a screen magnifier is being used, we won't be able to guarantee that the context menu and the current item that it's for will be on the screen at the same time, because they are often not near each other.
Assignee | ||
Comment 9•22 years ago
|
||
Seeking r=/sr=
Comment 10•22 years ago
|
||
Comment on attachment 101309 [details] [diff] [review] In nsEventListenerManager::HandleEvent, where we retarget the event if it's a NS_CONTEXTMENU_KEY event., this patch makes us retarget the event coordinates too (to use the focus coordinates) looks ok. have you tried it on pages with multiple frames, such as warp? or for a plugin? r=pink. i'll leave it to someone else to decide if this code really belongs in the ELM and content.
Attachment #101309 -
Flags: review+
Assignee | ||
Comment 11•22 years ago
|
||
Yep, I tested it on warp and the tinderbox iframe, as well as in prefs. I think it belongs there because that's where we retarget the node, and this just finishes the retargeting to get that node's coordinates as well. Besides, we have the variables we need to do it there. Seeking sr=
Comment 12•22 years ago
|
||
Comment on attachment 101309 [details] [diff] [review] In nsEventListenerManager::HandleEvent, where we retarget the event if it's a NS_CONTEXTMENU_KEY event., this patch makes us retarget the event coordinates too (to use the focus coordinates) sr=bryner
Attachment #101309 -
Flags: superreview+
Assignee | ||
Comment 14•22 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 15•22 years ago
|
||
testing with 2002.10.08.08 (comm trunk), the context menu now appears near the focused item. it doesn't obscure the item either. vrfy'ing fixed.
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•