1426671 - Context menu is always shown in the top left when activated from keyboard

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[5silentrain]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171206182557

Steps to reproduce:

1. Select any text on the page: http://jpegshare.net/ea/11/ea11d748c074df8b40011dbc36a59aaa.png.html
2. Click on the Menu key on your keyboard: http://jpegshare.net/b7/b8/b7b85dd3b2094eec452fed8431a6ce3c.jpg.html


Actual results:

The context menu appears in the upper left corner of the window: http://jpegshare.net/36/0d/360d5e3b237712c74e60bf31e60f679b.png.html


Expected results:

The context menu should appear below the selected text: http://jpegshare.net/8e/54/8e547069d3120b01bb629a74abbc9965.png.html

Comment 1

[5silentrain]

>2. Click on the Menu key on your keyboard

Or you can press Shift + F10.

Comment 2

[Flore Allemandou [:flore]]

How does it work in other browsers ?

Comment 3

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
20171221100108

Bug 81723
Bug 271498

Looks like this regressed again. It also happens in ESR 52.5.2, so this is really old.

Comment 4

[Gingerbread Man]

Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:2.2a1pre) Gecko/20110412 Firefox/4.2a1pre
Built from http://hg.mozilla.org/mozilla-central/rev/48d6abe0a436

It was an issue all the way back in Firefox 4.2a1pre, which is as far as mozregression-gui goes. I wonder if it's actually always been an issue in Firefox despite being fixed in the Mozilla Suite.

(In reply to Flore Allemandou [:flore] from comment #2)
> How does it work in other browsers ?

Vivaldi - context menu relative to the selection
IE, Edge - same bug as Firefox

Comment 5

[Flore Allemandou [:flore]]

I'm asking, because at work, I use an application on windows (not related to browsers) and the contextual menu triggered by the menu key is on top left of the window (as described in the bug) although it's correctly placed when triggered by right mouse click.
So I suspected a bug more common than just browsers.

Comment 6

[Neil Deakin]

This isn't a regression. It looks like the code which positions the context menu at the cursor position only does this when it is visible. It works fine when caret browsing is enabled (press F7).

The code in PresShell::PrepareToUseCaretPosition should instead be checking if the selection is not collapsed if the caret isn't visible and not returning early in this case.

Comment 7

[5silentrain]

If you press F7, select some text, and then press Shift+F10, the context menu will still be displayed in the top left corner of the window!
Compared to the behavior of the Chrome, it looks extremely stupid.

Comment 8

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
20180103230158

(In reply to Neil Deakin from comment #6)
> It works fine when caret browsing is enabled (press F7).

I'm still seeing the same bug with caret browsing on.

(In reply to 5silentrain from comment #7)
> If you press F7, select some text, and then press Shift+F10, the context
> menu will still be displayed in the top left corner of the window!
> Compared to the behavior of the Chrome, it looks extremely stupid.

Same here. Shift+F10 or the Menu key, same thing.

Comment 9

[Neil Deakin]

I meant that the correct behaviour occurs when caret browsing is enabled, and the caret is visible (that is, no selection). The logic just needs to be changed so that the same positioning also applies when there is a selection.

Comment 10

[reddysridhar53]

Is this issue been fixed? If not, Can I work on this?

Comment 11

[Gingerbread Man]

(In reply to reddysridhar53 from comment #10)
> Is this issue been fixed? If not, Can I work on this?

As you can see, the report is still open and no patches have been submitted. You're welcome to work on this.

Comment 12

[reddysridhar53]

@Ginger(In reply to Gingerbread Man from comment #11)
> (In reply to reddysridhar53 from comment #10)
> > Is this issue been fixed? If not, Can I work on this?
> 
> As you can see, the report is still open and no patches have been submitted.
> You're welcome to work on this.

Thank you, But I am unable to setup in my local machine. Git clone always fails around 30 - 40 %. Can you please help me with this?

Comment 13

[Gingerbread Man]

Comment 12.

Comment 14

[Neil Deakin]

Sorry, this isn't really the place to help with build issues. You might try one of the forums (https://www.mozilla.org/en-US/about/forums/) such as mozilla.dev.builds or ask on one of the mozilla irc channels.

Comment 15

[Daniel Almeida]

I've successfully built firefox and submitted a patch for bug 1447950.

Work here seems to have stalled. Can I take this over and get some mentoring if necessary?

Comment 16

[Daniel Almeida]

I'm stuck...

No matter what you have highlighted on the screen, or if caret browsing is enabled/disabled:

1.While breaking into PressShell::PrepareToUseCaretPosition() domSelection->Collapsed() always return true; caret->IsVisible() always returns false.

2.static_cast<mozilla::dom::Selection*>(domSelection)->GetRangeAt(0)->GetStartContainer()->GetAsText()->GetWholeText() always return the current URL. I thought this was supposed to somehow contain whatever text was just highlighted.


Also, wouldn't it be more intelligent to show the context menu right where the mouse pointer is? Makes it easier to click on it.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

This good-first-bug hasn't had any activity for 6 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Comment 18

[max]

I think, position of context menu is a consequence, the cause is incorrect target of contextmenu events. Execute in a web page console

window.addEventListener(
    "contextmenu",
    e => console.log("contextmenu target: %o", e.target),
    { capture: true })

and try right mouse click or [Menu]/[Shift+F10] after search ([Ctrl+F] or /) or when caret browsing is enabled. For keyboard navigation Firefox-113 reports <body>. Chromium-113 provides precise event target element after search, but <html> after moving keyboard caret within non-interactive text.

My primary interest is getting context menu target element in an add-on (see Bug #1835211), but, I am afraid, the feature depends on implementation in web engine.

Comment 19

[5silentrain]

I currently have a Mac mini and am using macOS. I use the Apple keyboard, that is, "Apple Magic Keyboard with Touch ID and Numeric Keypad". In this system, I did not find the ability to call the context menu using the keyboard 🤔

Comment 20

[max]

I have not found a way to invoke from keyboard a context menu for an image with specific entries. E.g. libreoffice has [Shift+F4] shortcut to select an image.

Despite contextmenu event is fired with <body> target, there are ways to obtain actual DOM element, e.g. document.elementFromPoint and elementsFromPoint:

window.addEventListener(
    "contextmenu",
    e => console.log("contextmenu: %o", document.elementsFromPoint(e.x, e.y)),
    { capture: true })

window.getSelection().focusNode is another way. For caret browsing selection is collapsed and has type: "Caret". It is applicable to the current search position as well, however selection has type: "Range". Of course heuristics that the caret is adjacent to an image requires more code.

P.S. I am not familiar with macOS, but perhaps context menu from keyboard is a subject of a dedicated feature request. My impression based on search engine results that it is not a native feature, however some applications implement it.

Comment 21

[5silentrain]

The same thing happens in macOS version 15, called Sequoia, when you press Ctrl+Enter.