GNOME Bugzilla – Bug 169364
Dialog box appearing upon dragging an URL onto desktop should be on top
Last modified: 2005-08-20 16:21:08 UTC
Open a web browser and drag an image or a link to the desktop. Nautilus displays a dialog box asking you whether you would like to download the target or to create a link to it. There are two issues with this functionality: 1) The dialog box is hidden by the browser window in many cases, where the user can't find it. It should be the topmost window. 2) The window has the caption "untitled window". Not nice.
*** Bug 170494 has been marked as a duplicate of this bug. ***
The changelog has this mention: 2005-01-27 Alexander Larsson <alexl@redhat.com> * src/file-manager/fm-directory-view.c: (ask_link_action): Set focus_on_map for dnd ask dialog to avoid it ending up under the browser window. Patch from Jorn Baayen <jbaayen@gnome.org> The code does: gtk_window_set_title (GTK_WINDOW (dialog), ""); /* as per HIG */ gtk_window_set_focus_on_map (GTK_WINDOW (dialog), TRUE); gtk_dialog_set_default_response (GTK_DIALOG (dialog), 2); gtk_window_present (GTK_WINDOW (dialog)); Elijah, any idea if that's a gtk or a nautilus issue?
The gtk_window_set_focus_on_map (GTK_WINDOW (dialog), TRUE); is totally useless; that function call doesn't do anything unless FALSE is specified since the default is true. Perhaps we should rename it or something, because it's only there as a way to request that something not be focused when it otherwise normally should, NOT to request to steal focus when you otherwise shouldn't be able to. The problem is that ask_link_action opens a window that is given an out-of-date _NET_WM_USER_TIME. Apparently, the _NET_WM_USER_TIME of the nautilus process is not updated when the user drops onto the background window. I don't know much of anything about how DND works, though, so I don't know who is responsible for such an update. I'm guessing, though, that this is a more general problem and it'd be great if it's something we could solve in gtk+ somewhere. I'll keep looking...
Created attachment 46309 [details] [review] Patch to bandaid the problem This patch fixes the observed behavior so that the window comes on top. It does so by updating the _NET_WM_USER_TIME of the desktop window when a url is dropped onto it. There are probably other things for which the _NET_WM_USER_TIME of the desktop window should be updated besides just dropping URLs. In fact, it may be the case that we want to unconditionally update the _NET_WM_USER_TIME of a window when something is dropped on it (which I believe would be done in gtkdnd.c:gtk_drag_selection_received from a quick search through the code). We'll probably need to ask the gtk guys, because I just don't know enough about DND.
gtk devs: In general do we want to update the _NET_WM_USER_TIME of a window when it is a drop target? I don't know much about DND, so I don't know if a window can be a drop target without it being considered user interaction. (see comment 4)
Drag: Probably shouldn't update the timestamp ... though spring-loaded folders could be a theoretical problem. (Simply dragging across a window is much like enter/leaves from motion events, which don't update the timestamp) Drop: Should update the timestamp.
Created attachment 46780 [details] [review] Have gtk+ update _NET_WM_USER_TIME stamp upon drop Okay, here's my attempt to make gtk+ update the USER_TIME timestamp upon drop. Don't know if it's right since I still don't really grok DND, but it does fix this nautilus issue, at least. Comments welcome.
Comment on attachment 46780 [details] [review] Have gtk+ update _NET_WM_USER_TIME stamp upon drop I'd expect this to be done in gdk/x11/gdkdnd-x11.c. xdnd_drop_filter() And, maybe for completeness motif_drop_start()
Created attachment 46821 [details] [review] New version, modifiying motif_drop_start() and xdnd_drop_filter() in gdk/x11/gdkdnd-x11.c Yeah, gdk does make more sense, doesn't it? Okay, here's try #2 to get the patch right; let me know what else I need to fix. :)
Patch looks right, committed.
*** Bug 308031 has been marked as a duplicate of this bug. ***
*** Bug 309816 has been marked as a duplicate of this bug. ***
*** Bug 313347 has been marked as a duplicate of this bug. ***
*** Bug 314038 has been marked as a duplicate of this bug. ***