bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Using ctrl+space to open context menu doesn't place the menu at the current mouse position




Widget: Cocoa
10 years ago
10 years ago


(Reporter: whimboo, Assigned: Josh Aas)


Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




10 years ago
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008030404 Minefield/3.0b5pre ID:2008030404

Now that bug 357540 is fixed you can use ctrl+space to open the context menu of the underlaying element. Using the right mouse button or ctrl+click opens the context menu directly at the mouse position. But if you are using the keyboard shortcut the context menu is opened in the left top corner of the browser window.

I would expect that both possible ways would open the context menu at the current mouse position.
This happens in Firefox 2 as well. Is there another bug to dupe this to?

Comment 2

10 years ago
Yes, did the wrong search. Lets dupe.
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 175568
Bug 175568 is really ancient, was supposedly fixed, and is probably irrelevant.

If at some point I start working on this, I'll probably have to undo the dup.

Comment 5

10 years ago
Feel free. We could also add it to the blocker list of this bug because it will fix a part of the mentioned issues reported in bug 175568.
> We could also add it to the blocker list of this bug because it will
> fix a part of the mentioned issues reported in bug 175568.

I'd feel more comfortable with that.

I think we should only dup bugs if they have the same symptoms _and
the same cause_.

But I think it's fine (and often very desirable) to indicate
relationships by setting the "depends on" and "blocks" fields ... or
just by mentioning another bug in one of a given bug's comments.

I'd actually like to see an additional "related" field, to indicate
relationships that are more tentative than "depends on" or "blocks".

Comment 7

10 years ago
Reopening and adding bug 175568 to the blocking list. When this bug is fixed it automatically fixes one issue which is mentioned in bug 175568.
Blocks: 175568
Resolution: DUPLICATE → ---

Comment 8

10 years ago
Since ctrl-space is an accessibility feature, maybe it isn't supposed to work the way we're all assuming it is. If the goal is to be able to expose more functionality from the keyboard, for a user that doesn't really use the mouse, perhaps ignoring the mouse position is a good thing'?

I don't know that it is true, it is a wild guess. We should really figure out what is supposed to happen first, cc'ing Aaron and Håkan.

Has someone tested this on Windows to see how their equivalent to ctrl-space works?

Comment 9

10 years ago
(In reply to comment #8)
> Has someone tested this on Windows to see how their equivalent to ctrl-space
> works?

I did that now. When no element has the focus the context menu is opened in the top-left corner of the tab. If you have focused an element it opens directly at its position when hitting the context menu key under Windows.

We should have a test again under OS X with setting the focus to the appropriate elements first.

But at least this wont allow us to open the context menu for images with the keyboard shortcut. Or am I wrong?

Comment 10

10 years ago
I kind of agree that it makes sense to connect the contextmenu with the element your invoking it on. Here's why: If I'm mouseless, and use this feature to navigate, it wouldn't make sense that all my contextmenus appeared in whatever random corner the cursor happens to lie. 

Keep in mind that I haven't used this feature before, but for the reason above I'd say WONTFIX.

Comment 11

10 years ago
(Clarification: by "cursor", I do not mean the currently focused element, but the mousecursor.)

Comment 12

10 years ago
Sorry my fault. You are right Hakan. I checked it again under OS X and Windows Vista. Using especially carret browsing and hitting Ctrl+Space on the focused element the context menu opens directly under it. We shouldn't respect the mouse position.

Marking WONTFIXED due to it doesn't make sense.
Last Resolved: 10 years ago10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.