Reproducible: always Steps To reproduce: 1. Launch Nightly Actual Results: After browser window display, mouse cursor turn to "progress"(Arrow+hourglass) shape. And it takes about 5 sec to turn to "default"(Arrow) shape. Expected Results: It should be less than 2 seconds to turn to "default"(Arrow) shape. Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=24d5dbf3a9dcadf708aa6874d9cfbe911af3d3d7&tochange=01fd73e4b8b89080505bf9f004c82c3e1043f40e Regressed by: Bug 1384336

Is this bug only about the cursor, or does the window take longer to finish painting as well?

It seems cursor only.

Let me add what I am seeing. A new profile and safe-mode displays the arrow/busy pointer for about 6 or 7 seconds before it turns to a regular pointer. If I have a home page open up when I start Fx the pointer behaves as mentioned above. However, if I open up to a blank page I get just the busy pointer which will last forever unless I do something else with the busy pointer like moving it over a toolbar. At this point it changes back to a normal pointer. Since this only happens on my production profile, with add-ons, this might be an add-on issue. Also, when I open up my first new tab after I start Fx I get the same arrow/busy pointer. After this, opening up a new empty tab behaves normally, no arrow/busy pointer until I exit and start Fx again.

It appears the Webextension add-on AutoplayStopper is the culprit causing the busy pointer when Fx opens up to a blank page. With AS disabled it produces the arrow/busy pointer for 6-7 seconds. I'll let the developer of AS know these findings.

This should be fixed by a backout in bug 1397956.

Re-opening this, so it can be addressed and we can hopefully turn off native event processing in bug 1423628. (I think I already have a fix for this one.)

Thanks Jim. https://treeherder.mozilla.org/#/jobs?repo=try&revision=1f0d236c8a9a473184bef516edb62e1ff74f3870

Pushed by bobowencode@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/74c0d505722a Use STARTF_FORCEOFFFEEDBACK flag when starting Windows child processes to prevent app starting cursor. r=jimm

What should the status of 57/58 be here?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #15) > What should the status of 57/58 be here? Sorry didn't spot that, this was triggered by turning off native event processing, but native event processing was re-enabled, because of this and other regressions. I'm working through the regressions, so we can try turning it off again.

Comment on attachment 8935035 [details] [diff] [review] Use STARTF_FORCEOFFFEEDBACK flag when starting Windows child processes to prevent app starting cursor Approval Request Comment [Feature/Bug causing the regression]: I realised that we have had the same problem with the GMP process since launch. [User impact if declined]: User currently gets 5-7 seconds background activity cursor every time we start a GMP process. Even though the video has already started. [Is this code covered by automated tests?]: The sandboxed process launch code is run in all e10s tests. [Has the fix been verified in Nightly?]: Yes. [Needs manual test from QE? If yes, steps to reproduce]: Yes. If you go to https://shaka-player-demo.appspot.com/demo/ you should see the background activity cursor for 5 to 7 seconds. (Assuming it doesn't get overridden for another reason, for example if you hover over a link.) [List of other uplifts needed for the feature/fix]: None. [Is the change risky?]: No. [Why is the change risky/not risky?]: Trivial one line change to add a standard flag to process start-up information. [String changes made/needed]: None.

Comment on attachment 8935035 [details] [diff] [review] Use STARTF_FORCEOFFFEEDBACK flag when starting Windows child processes to prevent app starting cursor Fix a (child process) startup issue that started in 57 - let's uplift this for 58 beta 12.

The patch cannot be uplifted to beta. grafting 454357:74c0d505722a "Bug 1395187: Use STARTF_FORCEOFFFEEDBACK flag when starting Windows child processes to prevent app starting cursor. r=jimm" other [graft] changed security/sandbox/chromium-shim/patches/after_update/patch_order.txt which local [local] deleted use (c)hanged version, leave (d)eleted, or leave (u)nresolved? Please take a look at this. Thanks!

(In reply to Cosmin Sabou [:cosmin_sabou] from comment #19) ... > Please take a look at this. Thanks! Sorry about that, I didn't have a copy of beta at the all hands and I forgot about the fact I've changed the way we store the patches for the chromium sandbox. This is an uplift, so we don't need that part anyway. Here's a patch with just the actual code change.

I have managed to reproduce this issue using the Nightly build 57.0a1 (20170830100230), on Windows 10 X64. I retested it using the latest Nightly 59.0a1 (20171219100203) and beta 58.0b12 (20171218174357), on the same platform and I can mark this issue as verified fixed.