[Webkit-unassigned] [Bug 49904] [GTK] Add a signal to allow applications to handle its own context menu

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=49904


Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #76383|0                           |1
        is obsolete|                            |
 Attachment #106400|                            |review?
               Flag|                            |




--- Comment #25 from Carlos Garcia Campos <cgarcia at igalia.com>  2011-09-06 02:45:10 PST ---
Created an attachment (id=106400)
 --> (https://bugs.webkit.org/attachment.cgi?id=106400&action=review)
New patch

After talking with Martin about this bug, we thought we could add a new class to handle the context menu and pass that new object as parameter of the new signal. Then I looked again at the patches and I realized we don't actually need a new class. Following the idea of passing the default context menu widget as a parameter to the signal, the only thing we would need to make menu modification easier is a well know name for every possible menu item, but I think that could be part fo a following patch, since it's actually another problem that we already have with the populate-popup signal. So, this patch adds a new context-menu signal that passes the default menu, a hit test result and whether it was triggered by keyboard. I've added x and y properties to WebKitHitTestResult so that we don't need to pass x, y as signal parameters, like previous patches did. The hit test result already contains the coordinates (relative ot the view's window) that the client can use when the menu 
 is triggered by the keyboard to position the menu.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.