CEF3 - CefContextMenuParams and X, Y coordinates

[nesffs]

Hi. While trying to figure out the problem outlined in http://code.google.com/p/chromiumembedd ... ail?id=602, I noticed that the X, Y coordinates returned by CefContextMenuParams::GetXCoord and CefContextMenuParams::GetYCoord, respectively, are "relative to the associated RenderView's origin."

Code: Select all

// Provides information about the context menu state. The ethods of this class
// can only be accessed on browser process the UI thread.
///
/*--cef(source=library)--*/
class CefContextMenuParams : public virtual CefBase {
 public:
  typedef cef_context_menu_type_flags_t TypeFlags;
  typedef cef_context_menu_media_type_t MediaType;
  typedef cef_context_menu_media_state_flags_t MediaStateFlags;
  typedef cef_context_menu_edit_state_flags_t EditStateFlags;

  ///
  // Returns the X coordinate of the mouse where the context menu was invoked.
  // Coords are relative to the associated RenderView's origin.
  ///
  /*--cef()--*/
  virtual int GetXCoord() =0;


This is different from the CEF1 counterpart where the on-screen rendering option affects the X, Y values:

Code: Select all

// Structure representing menu information.
///
typedef struct _cef_handler_menuinfo_t
{
  ///
  // Values from the cef_handler_menutypebits_t enumeration.
  ///
  int typeFlags;

  ///
  // If window rendering is enabled |x| and |y| will be in screen coordinates.
  // Otherwise, |x| and |y| will be in view coordinates.
  ///
  int x;
  int y;


To maintain the CEF1 behavior with on-screen rendering enabled, I would have to do something similar to CEF1 in browser_webview_delegate_win.cc, but using the browser's window handle (accessed through CefBrowserHost):

Code: Select all

void BrowserWebViewDelegate::showContextMenu(
    WebFrame* frame, const WebContextMenuData& data)
{
  int screenX = -1, screenY = -1;
 
  POINT mouse_pt = {data.mousePosition.x, data.mousePosition.y};
  if (!browser_->IsWindowRenderingDisabled()) {
    // Perform the conversion to screen coordinates only if window rendering is
    // enabled.
    MapWindowPoints(browser_->UIT_GetWebViewWndHandle(), HWND_DESKTOP,
        &mouse_pt, 1);
    screenX = mouse_pt.x;
    screenY = mouse_pt.y;
  }


I was just wondering if this interface change was intentional.

If we intend to use the X, Y coordinates relative to the screen (and not relative to the Renderview), then is it up to us to do the conversion ourselves? If so, is it correct in all cases to use the browser window handle for this conversion?

Thanks!

[magreenblatt]

I was just wondering if this interface change was intentional.

Intentional but not closed to debate. I think it's generally more useful and cross-platform to give view-based coordinates instead of screen-based coordinates.

If we intend to use the X, Y coordinates relative to the screen (and not relative to the Renderview), then is it up to us to do the conversion ourselves? If so, is it correct in all cases to use the browser window handle for this conversion?

Yes, the browser window handle can be used for conversion. The RenderView will always completely fill the browser window's content area.