We just need to implement GtkWidget::popup-menu and emit a fake right click event.
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.
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
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.
(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! :)
(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."
(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.
(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.
(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.
*** This bug has been marked as a duplicate of bug 72099 ***