Bug 75380 – [GTK] Allow to show context menu with keyboard in WebKit2 GTK+

• Component: WebKit2
• Status: RESOLVED DUPLICATE

[Carlos Garcia Campos]

We just need to implement GtkWidget::popup-menu and emit a fake right click event.

[Carlos Garcia Campos]

Created attachment 120787 [details]
Patch

We don't have access to the current focused node, so it always shows the menu at the top-left corner like GtkLauncher and Firefox do when there's no focused node nor selections.

[WebKit Review Bot]

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

[Martin Robinson]

Comment on attachment 120787 [details]
Patch

This actually isn't going to work, because it's going to determine the contents of the menu by doing a hittest at the location of the mouse event. For this to be accessible we need to get the currently focused node. I'll CC Joanie here because she has all of the requirements for this feature.

[Joanmarie Diggs]

(In reply to comment #3)
> (From update of attachment 120787 [details])
> This actually isn't going to work, because it's going to determine the contents of the menu by doing a hittest at the location of the mouse event. For this to be accessible we need to get the currently focused node. I'll CC Joanie here because she has all of the requirements for this feature.

I think you do as well, Martin. ;) So I'm guessing that there's some particular aspect I'm not thinking of. In the meantime.... 

The context menu should base its context about what the user is in or on.

* If that's a link, the menu should be for the link.
* If it's a widget, it should be for that widget.
* If the user is arrowing around the document via caret nav, it should be for the document.

In the last case if, say, the caret is within a paragraph does that mean the focused node is that paragraph? If so, unless non-focusable content can have a unique context menu, I suppose you do not always need the currently focused node; just the currently-focused focusable element.

If I failed to address any point which needs addressing, please let me know. And thanks for asking! :)

[Martin Robinson]

(In reply to comment #4)

> In the last case if, say, the caret is within a paragraph does that mean the focused node is that paragraph? If so, unless non-focusable content can have a unique context menu, I suppose you do not always need the currently focused node; just the currently-focused focusable element.

Perhaps it may be simpler to create a new IPC message that means "create a context menu event for the currently focused node."

[Carlos Garcia Campos]

(In reply to comment #3)
> (From update of attachment 120787 [details])
> This actually isn't going to work, 

This works.

> because it's going to determine the contents of the menu by doing a hittest at the location of the mouse event. For this to be accessible we need to get the currently focused node. I'll CC Joanie here because she has all of the requirements for this feature.

The behaviour is exactly the same than wk1 or firefox when there isn't a focused item or selection. When wk2 allows to get the rectangle of the current focused node or selection we can just improve it to use it like I already did for wk1.

[Martin Robinson]

(In reply to comment #6)

> This works.

Okay. I agree this works when there is no focused node, but I think it's possible to create a more general solution that actually meets our accessibility requirements right now.

> The behaviour is exactly the same than wk1 or firefox when there isn't a focused item or selection. When wk2 allows to get the rectangle of the current focused node or selection we can just improve it to use it like I already did for wk1.

It's probably saner to just create a new IPC message than to try to determine the focused node in the UIProcess.

[Carlos Garcia Campos]

(In reply to comment #7)
> (In reply to comment #6)
> 
> > This works.
> 
> Okay. I agree this works when there is no focused node, but I think it's possible to create a more general solution that actually meets our accessibility requirements right now.
> 
> > The behaviour is exactly the same than wk1 or firefox when there isn't a focused item or selection. When wk2 allows to get the rectangle of the current focused node or selection we can just improve it to use it like I already did for wk1.
> 
> It's probably saner to just create a new IPC message than to try to determine the focused node in the UIProcess.

I've just found this bug https://bugs.webkit.org/show_bug.cgi?id=72099. That solution looks better than mine and we don't need to create a new IP message.

[Carlos Garcia Campos]

*** This bug has been marked as a duplicate of bug 72099 ***