Comment 5 for bug 1040313

Revision history for this message
In , Foudil-newbie+bugzilla-mozilla-org (foudil-newbie+bugzilla-mozilla-org) wrote :

Created attachment 632872
basic implementation

See attachment for a basic/proof-of-concept implementation: nativeHandle returns the actual address of the native window as a jsval (not a pointer as one could expecte).

However, I begin to have doubts about the usefulness of such a property:

1. getting a handle is relatively easy with ctypes. Extensions do that well already: see http://forums.mozillazine.org/viewtopic.php?f=19&t=2449775 (windows) or https://addons.mozilla.org/en/firefox/addon/firetray/ (linux).

2. I can't seem to be able to make use of the memory address provided by nativeHandle: I can build a ctypes object out of it (gdk.GdkWindow.ptr), but it does not behave properly when I try to manipulate it, for example when fetching the GtkWindow stored in the user_data of the GdkWindow.

Here is how I re-construct the ctypes window object:

  let baseWin = win.QueryInterface(Ci.nsIInterfaceRequestor)
    .getInterface(Ci.nsIWebNavigation)
    .QueryInterface(Ci.nsIDocShellTreeItem)
    .treeOwner
    .QueryInterface(Ci.nsIInterfaceRequestor)
    .nsIBaseWindow;
  let nativeHandle = baseWin.nativeHandle;
  let gdkwPtr = ctypes.uintptr_t(nativeHandle).address();
  let gdkWindow = ctypes.cast(gdkwPtr, gdk.GdkWindow.ptr);