1566808 - Working in Background pointer appears when starting Fx Nightly.

Status: VERIFIED FIXED

(Core :: DOM: Content Processes, defect)

Description

[Gary [:streetwolf52]]

Attachment: Example of WiB pointer

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Start Fx Nightly.

Actual results:

Pointer is now the Working in Background pointer for about 6 seconds then changes to the normal arrow pointer.

Expected results:

Pointer should be the normal arrow pointer, unless this change is by design.

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6f82e91f3797d03f1839cd93126836b45b6b13e5&tochange=8ec55eb4aed6d7585abef387e952da42d9f5f422

Regressed by: Bug 1555792

Comment 3

[Byron Campen [:bwc]]

Interesting. Maybe this is similar to bug 1556109? What exactly does the "working in background" cursor mean anyway?

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Byron Campen [:bwc] from comment #3)

[...] What exactly does the "working in background" cursor mean anyway?

Please see attachment, as it's shown there.

Comment 5

[Gary [:streetwolf52]]

There is a workaround. Go into your Windows mouse settings and under pointers change the WIB cursor to the arrow cursor. Having done this the other day I haven't run into any problems with anything, so far.

Comment 6

[Byron Campen [:bwc]]

(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #4)

(In reply to Byron Campen [:bwc] from comment #3)

[...] What exactly does the "working in background" cursor mean anyway?

Please see attachment, as it's shown there.

I know what it looks like. My question is about what it actually means. Does it mean that main thread is waiting on some other thread? Does it mean that a background thread is blocking or otherwise non-responsive?

Comment 7

[Byron Campen [:bwc]]

Maybe mjf has run into something similar when working on RDD.

Comment 8

[Michael Froman [:mjf]]

I haven't noticed it prior to this report. However, when I launch 68, I see the "working in background" cursor for a brief period (less than a second). To me this means this isn't entirely new behavior (switching the cursor back and forth), but whatever it indicates is taking longer than it did previously.

Comment 9

[Michael Froman [:mjf]]

Two things I've noticed on my Win10 VM:

1. Setting network.process.enabled causes the behavior to resemble 68's behavior (very short WiB cursor).
2. The visible WiB cursor doesn't seem to affect the ability to type in the url bar or navigate to new pages.

I'm not sure this is actually a problem. Depending on the answer to "What does the WiB cursor actually mean?" this could be intended behavior.

Comment 10

[Byron Campen [:bwc]]

Ok, I'm just guessing here, but maybe this is because we are starting the networking process synchronously?

https://searchfox.org/mozilla-central/rev/b9041f813de0a05bf6de95a145d4e25004499517/netwerk/ipc/SocketProcessHost.cpp#117

This code runs on main thread, and waits until the socket process is up. Perhaps we should be doing this asynchronously? We have async init for the SocketProcessBridge here.

Comment 11

[Byron Campen [:bwc]]

^

Comment 12

[Jim Mathies [:jimm]]

Didn't we fix this a while back for content processes? Bob, I think you may have worked on that, or maybe David?

Comment 13

[Gary [:streetwolf52]]

It was similar except that time it was the busy cursor that lasted for 5-6 seconds. IIRC I don't think you could do anything until the busy cursor became an arrow cursor. I recall being able to click on a toolbar to get the arrow back.

Comment 14

[Bob Owen (:bobowen)]

(In reply to Jim Mathies [:jimm] from comment #12)

Didn't we fix this a while back for content processes? Bob, I think you may have worked on that, or maybe David?

Yes that was bug 1395187, but in that case it was because (IIRC) I was trying to turn off any Windows message processing in the content process and you get that cursor until any GUI related calls or (in the case of what I was trying to do) GetMessage.
The GMP process doesn't make any GUI related calls either, so we needed it for that as well.

(In reply to Byron Campen [:bwc] from comment #6)
...

I know what it looks like. My question is about what it actually means. Does it mean that main thread is waiting on some other thread? Does it mean that a background thread is blocking or otherwise non-responsive?

The STARTF_FORCEOFFFEEDBACK flag and its opposite (along with why the cursor appears in this case) are described here [1].

I guess the socket process doesn't make any GUI calls, but isn't sandboxed at the moment and so is launched through the IPC code.
We may well be able to fix this by adding that flag to that code here [2].
I think we could do that unconditionally because we don't want child process launch to affect the cursor like that.

[1] https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/ns-processthreadsapi-_startupinfoa
[2] https://searchfox.org/mozilla-central/rev/4436573fa3d5c4311822090e188504c10c916c6f/ipc/chromium/src/base/process_util_win.cc#309

Comment 15

[Kershaw Chang [:kershaw]]

(In reply to Bob Owen (:bobowen) from comment #14)

(In reply to Jim Mathies [:jimm] from comment #12)

Didn't we fix this a while back for content processes? Bob, I think you may have worked on that, or maybe David?

Yes that was bug 1395187, but in that case it was because (IIRC) I was trying to turn off any Windows message processing in the content process and you get that cursor until any GUI related calls or (in the case of what I was trying to do) GetMessage.
The GMP process doesn't make any GUI related calls either, so we needed it for that as well.

(In reply to Byron Campen [:bwc] from comment #6)
...

I know what it looks like. My question is about what it actually means. Does it mean that main thread is waiting on some other thread? Does it mean that a background thread is blocking or otherwise non-responsive?

The STARTF_FORCEOFFFEEDBACK flag and its opposite (along with why the cursor appears in this case) are described here [1].

I guess the socket process doesn't make any GUI calls, but isn't sandboxed at the moment and so is launched through the IPC code.
We may well be able to fix this by adding that flag to that code here [2].
I think we could do that unconditionally because we don't want child process launch to affect the cursor like that.

[1] https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/ns-processthreadsapi-_startupinfoa
[2] https://searchfox.org/mozilla-central/rev/4436573fa3d5c4311822090e188504c10c916c6f/ipc/chromium/src/base/process_util_win.cc#309

Thanks for the information. I'll try to do this or make the way to launch socket process more like RDD process.

Comment 16

[Kershaw Chang [:kershaw]]

Attachment: Bug 1566808 - Add STARTF_FORCEOFFFEEDBACK when launching process on windows

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b60e3b91037e
Add STARTF_FORCEOFFFEEDBACK when launching process on windows r=bobowen

Comment 18

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/b60e3b91037e

Comment 19

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm confirming that bug is fixed, starting in Mozilla Firefox Nightly 70.0a1 (2019-07-30), so I'm marking this bug as VERIFIED.
Thank you very much! \o/