bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.
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?
Yes, did the wrong search. Lets dupe.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 175568
Status: RESOLVED → VERIFIED
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.
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".
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.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
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?
(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?
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.
(Clarification: by "cursor", I do not mean the currently focused element, but the mousecursor.)
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.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago → 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.