GNOME Bugzilla – Bug 760694
W32: Apps linked with -mwindows make cursor busy sometimes
Last modified: 2016-03-14 11:34:34 UTC
Even though GetStartupInfo() in g_win32_run_session_bus() would tell us that STARTF_FORCEONFEEDBACK flag is not set, it still affects the rundll32 process for some reason. This means that Windows WM changes mouse cursor to IDC_APPSTARTING for a few seconds when rundll32 runs g_win32_run_session_bus(). Since g_win32_run_session_bus() never satisfies the conditions set by STARTF_FORCEONFEEDBACK, the busy cursor only goes away after a timeout. How to reproduce: 1) run: cmd 2) cd into directory where libgio-2.0-0.dll is 3) run: %SystemRoot%\system32\rundll32.exe libgio-2.0-0.dll,g_win32_run_session_bus@16 Mouse cursor will show that it's busy for a few seconds. This happens in the wild when a GApplication (usually GtkApplication) that is linked with -mwindows is started and there's no rundll32-hosted gdbus present, which causes gdbus session daemon to be started in a way shown above. Gedit is one such application. This affects the i686 build of glib/gdbus running on x86_64 NT 6.1.7601. Note that running this: %SystemRoot%\syswow64\rundll32.exe libgio-2.0-0.dll,g_win32_run_session_bus@16 does not produce this bug, which would suggest that it might be caused by an interplay between SysWoW64 and rundll.
Created attachment 319155 [details] [review] W32: eliminate busy cursor when a rundll32-hosted child runs Even though GetStartupInfo() in g_win32_run_session_bus() would tell us that STARTF_FORCEONFEEDBACK flag is not set, it still affects the rundll32 process for some reason. This means that Windows WM changes mouse cursor to IDC_APPSTARTING for a few seconds when rundll32 runs g_win32_run_session_bus(). Since g_win32_run_session_bus() never satisfies the conditions set by STARTF_FORCEONFEEDBACK, the busy cursor only goes away after a timeout. Fix this by explicitly running GetMessage(). To ensure that GetMessage() doesn't block, post a quit message immediately before calling it.
Hi LRN, Hmm, I think if the issue is the busy cursor, we could probably use STARTF_FORCEOFFFEEDBACK (or something like that) explicitly in the GetStartupInfo() call, which would make the busy cursor not go on. My take on this. With blessings, thank you. P.s. I might be a bit slower in responding this week due to Chinese New Year, lots of family gatherings during this festive week. Sorry in advance.
(In reply to Fan, Chun-wei from comment #2) > Hmm, I think if the issue is the busy cursor, we could probably use > STARTF_FORCEOFFFEEDBACK (or something like that) explicitly in the > GetStartupInfo() call, which would make the busy cursor not go on. > Elaborate please. Do we actually *add* STARTF_FORCEOFFFEEDBACK to startupinfo struct of every process glib spawns? What about the cases when glib spawns GUI programs that *do* need feedback?
Hi LRN, (Sorry for not getting back to this earlier...) Ah, I see, it doesn't seem that easy to add STARTF_FORCEOFFFEEDBACK, since that is within the internals of GLib... Sorry! Probably what you have here would be the best way to go. With blessings, thank you!
Attachment 319155 [details] pushed as 74b1dd87b5ff10ded5a09a10c36722aa5548ad63