CefClient for Linux Drag and Drop issues Post Aura

[Mayhew]

Drag and Drop is not working in CEFClient for Linux due to an issue between X11 and GTK.

There is currently an issue filed https://code.google.com/p/chromiumembedded/issues/detail?id=1258

I'm starting a thread here to discuss this outside of the bug in order to get some help while I attempt to debug the issue.

My first question is regarding a 1 pixel by 1 pixel window that shows up in the xwininfo check for the CefClient. I'm curious what this window is.
xwininfo: Window id: 67108867 "Google" (This is the GTK Main Window)
----2 children:
----62914561 (has no name): () 2502x1576+0+0 +58+24 (This is the CefX11Window)
--------1 child:
--------62914562 (has no name): () 2502x1576+0+0 +58+24 (I think this is the CefWindowDelegateView)
------------1 child:
------------69206019 (has no name): () 2502x1576+0+0 +58+24 (Not sure what this is yet)
----67108868 (has no name): () 1x1+-1+-1 +57+23 <--------------------------------------What is this window?

A xwininfo for CEFSimple does not show this
xwininfo: Window id: 77594625 "Google"
-----1 child:
-----77594626 (has no name): () 800x600+0+0 +58+52
--------1 child:
--------79691779 (has no name): () 800x600+0+0 +58+52

[Mayhew]

Okay, things are progressing slowly but I even see some issues with CefSimple and its drag/drop handling.

I see an issue with CefWindowX11::DispatchEvent() where it uses
::Window topmost_window = finder.FindWindowAt(bounds.origin());

It appears that when CefSimple launches this FindWindowAt call is made before the app is shown and the topmost_window will be whatever window was in that location before CefSimple launches. This causes CefWindowX11::DispatchEvent to set kXdndProxy on that unrelated window to be the CefWindowDelegateView.

Then if you start a drag in that unrelated app window, Xdnd messages are relayed to the CefSimple window and things get wonky pretty fast.If you happen to have the desktop proxy get set, things get locked up pretty fast.

So in short, DND doesn't work correctly in CEFSimple yet either.

I have put a lot of logging in the relevant classes and here is what I see for CefSimple

Window 58720257 was whatever window was behind the area where CEF Simple appears while it was being launched. In my case it was a chrome browser tab

an xwndinof -all -int call for the CefSimple app shows
xwininfo: Window id: 65011713 "Google" (This is the CefX11Window)
1 child:
65011714 (has no name): () 800x600+0+0 +58+52 (This is thie CefWindowDelegateView)
1 child:
67108867 (has no name): () 800x600+0+0 +58+52 (I assume the Aura contents view of the browser)

Here is the DND setup sequence
PlatformCreateWindow created CefWindowX11 with id=65011713
DesktopWindowTreeHostX11 created
DesktopDragDropClientAuraX11 Setting XdndAware on 65011714
PlatformCreateWindow created CefWindowDelegateView as a child of 65011713
CefWindowX11::DispatchEvent thinks topmost_window=58720257 and proxy_target=0 (This is wrong and is an unrelated window)
CefWindowX11s id=65011713 and its first child is 65011714
CefWindowX11::DispatchEvent setting kXdndProxy on 58720257 to 65011714 (This is very bad)
CefWindowX11::DispatchEvent thinks topmost_window=65011713 and proxy_target=0 (Now things are getting back on track, I assume because the window has been shown)
CefWindowX11s id=65011713 and its first child is 65011714
CefWindowX11::DispatchEvent setting kXdndProxy on 65011713 to 65011714
Running without renderer sandbox
CefWindowX11::DispatchEvent thinks topmost_window=65011713 and proxy_target=65011714
CefWindowX11s id=65011713 and its first child is 65011714

[Mayhew]

Another update. I got the drag/drop test page working in CefClient for linux.

I'm still trying to find the real fix but there are two issues I see
1) kXdndProxy is only set in a ConfigureNotify and in the CefCient case, this event is not fired on app startup. It only happens when you resize the main GTK window. Not doing this causes no proxy to be set.
2) kXdndProxy is not set to the correct window.
A) In the CefSimple case the initial event ConfigureNotify handled results in FindWindowAt() returning whatever window was at the bound.origin() point under the app window. This could be the desktop, etc. The code sets the proxy for this window to be the child of the CefWindowX11. Then a second ConfigureNotify event comes in and FindWindowAt() then returns the CefWindowX11 itself and the proxy is then set properly. The initial windows proxy will remain until it is closed.
B) In the CefClient case FindWindowAt() never returns an app in the window tree of the app. It always returns some window above the GTK main window, usually the "unity-launcher". So the proxy is never correctly set to the CefWindowX11's parent window, which should be CefClients main GTK Window.

I'm not yet sure how to address item 1.

My hack for Item two was to add the following after the ::Window topmost_window = finder.FindWindowAt(bounds.origin()); line
if (topmost_window != xwindow_ || topmost_window != parent_xwindow_) {
if (parent_xwindow_ != None && parent_xwindow_ != DefaultRootWindow(xdisplay_)) {
topmost_window = parent_xwindow_;
} else {
topmost_window = xwindow_;
}
}
This assumes that the proxy should be set to either the CefWindowX11 (in the cefsimple case) or the CefWindowX11's parent (in the CefClient use case). The real fix however may need to happen in FindWindowAt() itself but changing that could have wide reaching implications beyond the scope of this bug.

If anyone with more experience in this part of the code has any suggestions, fire away. I'd love to hear your suggestions.

[Mayhew]

FYI that change for item 2 is in CefWindowX11::DispatchEvent() in the ConfigureNotify case.

[Mayhew]

This has also exposed another problem in the cef client. The HTML5 drag drop test page will only work if the cefclient is positioned at the top left corner of the linux desktop. If you move the window right and down, the drop area never highlights.

[Mayhew]

Looking at X11TopmostWindowFinder::FindWindowAt() it seems that this is not the best method for what it is used for in CefWindowX11::DispatchEvent. It is designed to get any window at the specified position and not necessarily one related to the CefWindowX11's tree at all.

I'm thinking the fix for setting the incorrect proxy should be to simply set the proxy on CefWindowX11::xwindow_ if CefWindowX11 was constructed with no parent window. If it was constructed with a parent window, then the proxy is set directly on parent_xwindow_. The only issue there would be if the CefWindowX11 was hosted multiple window levels deep in an application, but even then that may be the correct window to set the proxy on.

I'm also thinking the proxy setup code should move out of CefWindowX11::DispatchEvent() to avoid requiring a resize/move in order to ensure the proxy is set. Seems like this should be done somewhere like CefWindowX11::Show() in the if (!window_mapped_) conditional.

Marshall, any thoughts on this?

[magreenblatt]

This has also exposed another problem in the cef client. The HTML5 drag drop test page will only work if the cefclient is positioned at the top left corner of the linux desktop. If you move the window right and down, the drop area never highlights.

This is probably related to the DesktopWindowTreeHostX11 changes in https://code.google.com/p/chromiumembed ... ail?r=1759.

Looking at X11TopmostWindowFinder::FindWindowAt() it seems that this is not the best method for what it is used for in CefWindowX11::DispatchEvent. It is designed to get any window at the specified position and not necessarily one related to the CefWindowX11's tree at all.

Right, we should use a window in the CefWindowX11 tree hierarchy.

I'm thinking the fix for setting the incorrect proxy should be to simply set the proxy on CefWindowX11::xwindow_ if CefWindowX11 was constructed with no parent window. If it was constructed with a parent window, then the proxy is set directly on parent_xwindow_. The only issue there would be if the CefWindowX11 was hosted multiple window levels deep in an application, but even then that may be the correct window to set the proxy on.

The problem is that XdndProxy needs to be set on the top-level application window. IIRC DnD messages are only sent to the top-level window by the window manager and won't be forwarded correctly otherwise.

I'm also thinking the proxy setup code should move out of CefWindowX11::DispatchEvent() to avoid requiring a resize/move in order to ensure the proxy is set. Seems like this should be done somewhere like CefWindowX11::Show() in the if (!window_mapped_) conditional.

I wonder if there's an event that is sent on initial CEF window creation and when the CEF window is re-parented to a different window after initial creation. Maybe the show event already triggers in both cases, in which case we can just use that event.

[Mayhew]

Thanks,
I'll look at the DesktopWindowTreeHostX11 changes. It seems like a coordinate conversion error when CefWindowX11 is parented vs. being a top level window.

Right, we should use a window in the CefWindowX11 tree hierarchy.
The problem is that XdndProxy needs to be set on the top-level application window. IIRC DnD messages are only sent to the top-level window by the window manager and won't be forwarded correctly otherwise.

I'll try writing a helper method in CefWindowX11 to walk up the parents until it finds a window with a parent equal to DefaultRootWindow(xdisplay_). That should always get the topmost window in the browsers window tree.

I wonder if there's an event that is sent on initial CEF window creation and when the CEF window is re-parented to a different window after initial creation. Maybe the show event already triggers in both cases, in which case we can just use that event.

Initial testing seems to indicate Show should work. My only concern here is will putting this here break any off screen rendering case where Show may never be called?

[magreenblatt]

My only concern here is will putting this here break any off screen rendering case where Show may never be called?

We don't have an example implementation of DnD with off-screen rendering on Linux yet. The client needs to handle DnD events and call CefBrowserHost methods.

[Mayhew]

I'll try writing a helper method in CefWindowX11 to walk up the parents until it finds a window with a parent equal to DefaultRootWindow(xdisplay_). That should always get the topmost window in the browsers window tree.

This doesn't work as I would have expected. It seems that there are other parent windows above the main app window before the root. I'm not currently sure the best way to determine the main app window given a Window in CefWindowX11.

Another approach would be to expose a method that Linux client apps could call to set the dnd proxy manually. In this API the caller could pass their main apps Window. Just a thought.