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)

defect
Not set
normal

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.
eh. i just did what IE does.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
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
nice to fix if we get to it
Severity: minor → normal
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?
Keywords: access
QA Contact: jrgm → sairuh
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.
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+
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 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+
taking
Assignee: pinkerton → aaronl
Status: ASSIGNED → NEW
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: