It would be nice if the webkit_open_page could set the mouse pointer to busy while loading a page.
This is a duplicate of bug http://bugs.webkit.org/show_bug.cgi?id=16205
*** Bug 16205 has been marked as a duplicate of this bug. ***
So, bdash told me yesterday that WebKit does not do this (and has never done it). If it should be done on Application side this bug should be closed as INVALID/WONTFIX.
Unlike for example gtkmozembed WebKit does not normally apply a loading pointer on its own. In many non-browser use cases this is the desired behavior. Instead you should make use of gdk_window_set_cursor in a "load-progress-changed" callback.
BTW: while I don't have anything against doing this in app-side, we need some API hooks to do it correctly I think. Unconditionally setting cursor on load-progress-changed is wrong: if you are hovering a link, for example, the cursor should remain as a "hand" all the time, but we'd switch it to a "watch/wait" when the next progress-change happens.A signal would a good way of doing this, but any other way would do. Or if anybody knows how Safari or other WebKit browser handles this, that might help too :)
Yeah, I think it's OK for us to support this in WebCore directly, though it might be worth providing a way to turn it off. Xan, can you try adding a setPointerCursor() (or maybe pushPointerCursor()/pop if you're feeling elaborate) to Cursor.h? Then we can just call this from somewhere doing the loading.
Created attachment 18875 [details] useloadingcursor.diff Quick and dirty patch. - I'm using just a bool value in CursorGtk to decide if I return pointerCursor or waitCursor in the pointerCursor function. I think this is good enough? The static variable might be anathema in C++, maybe we can replace it with some class variable or something...? - Might want to cache the value of the setting in FrameLoaderClientGtk and connect to notify::use-loading-cursor to update the value. Tested this with Epiphany, it works ok.
*** Bug 26579 has been marked as a duplicate of this bug. ***
Found this old bug. In Chrome we have to do some work to get the cursor+hourglass cursor that Firefox (and now Chrome) uses. You can take a glance through the Chrome cursor code to see how it works. (It's pretty hacky.)
Created attachment 225352 [details] Patch
Comment on attachment 225352 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=225352&action=review > Tools/MiniBrowser/gtk/BrowserWindow.c:485 > + GdkWindow *gdk_window = gtk_widget_get_window(GTK_WIDGET(window->webView)); We use camelCase here, I think. So, gdkWindow ? > Tools/MiniBrowser/gtk/BrowserWindow.c:493 > + gdk_window_set_cursor(gdk_window, lastCursor); I suppose it's alright to not check lastCursor is non-null here, right? Passing NULL means use the cursor of the parent window.
Pretty sure we don't want this ATM.