Able to reproduce the issue on reported chrome version 63.0.3239.108 and on the latest canary 65.0.3306.0 using Windows 10 as per the steps mentioned in comment#0 by reporter.
As the issue is seen from M50(50.0.2641.0) considering it as non-regression, hence marking it as Untriaged.

Note: The issue is not seen on Ubuntu 14.04 and Mac 10.13.1.

Thanks!

I've seen this before as well.  James, do you know who knows about the mouse cursor?

Sorry, I'm not sure how this particular functionality is wired in, especially on Windows (10), and I'm not sure off-hand who knows this stuff well.

+girard@ who knows more about Win system stuff than I do.

@jschuh, do you have any ideas about this?

I believe it's correlated with spawning renderer processes.  Windows will show this cursor if a new process doesn't call GetMessage (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms686331.aspx, comments on STARTF_FORCEONFEEDBACK).

@brucedawson, @groby - Could one of you route this to someone on Windows?

This is probably a question for +robliao, who'll be back soon-ish, or +chengx.

robliao, will you be able to do this? It looks straightforward, but ???

See also  bug 795546 , an annoying and repetitive manifestation of this bug.

I took a look into this around Jan 10 but forgot to add the details!

STARTF_FORCEONFEEDBACK didn't seem to have much of an effect in hiding the application starting cursor. The investigating ended around digging into the kernel.

Silly question - do you mean that you tried STARTF_FORCEOFFFEEDBACK, rather than STARTF_FORCEONFEEDBACK?  That's the flag I would have guessed we need here.

 Issue 813840  has been merged into this issue.

There is a related issue (new to M64?) where M64, we spawn a helper process to enumerate video devices. This helper process triggers this cursor glitch every 5-10 seconds. I can't find the relevant bug.

Re comment 11: I used Windbg[1] to change lpStartupInfo->dwFlags to be 0x81 (STARTF_FORCEOFFFEEDBACK | STARTF_USESHOWWINDOW) and the resulting calls to CreateProcess still changed the application cursor. It seems that FORCEOFFFEEDBACK doesn't in this case.

[1] on Windows 10:
bp kernel32!CreateProcessWStub "dd poi(rsp+48)+40 L 1; ed poi(rsp+48)+40 81; dd poi(rsp+48)+40 L 1; g"

#14. That agrees with my analysis. I made a typo in #10!

I was experiencing this issue with one of my own applications which spawns as a non-console process but does not use a GUI. A workaround is to send and receive a dummy message as close as possible to the application start, eg:

MSG msg;
PostMessage (NULL, WM_NULL, 0, 0);
GetMessage (&msg, NULL, 0, 0);

This still causes the busy-waiting cursor to show very briefly, but it is much nicer than having it linger for the full two seconds.

I can confirm this issue on all my workstation with Win 10 (1803) OS. Chrome 66 constantly show busy cursor during and after loading page, open net tab etc. much more than other OS for example Win7. Can anyone know when we can expect fix for this issue?

Just now I received chrome 67 update and it's looks like issue has gone. Many many thanks for developers team.

I can also confirm that this seems resolved in Chrome 67.