Installer Progress Bar is stuck while the installation window is moved around the screen
Categories
(Firefox :: Installer, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | affected |
People
(Reporter: cbadau, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
5.76 MB,
image/gif
|
Details |
Affected versions
- 77.0a1 (20200423214309)
Affected platforms
- Windows 10 x64
- Windows 8.1 x64
Steps to reproduce
- Download and run the Stub Installer.
- Click ->hold-> and move the installation window around the screen.
Expected result
- The installation progress is correctly displayed while the installation window is moved around the screen.
Actual result
- The Progress Bar is stuck while the installation window is moved around the screen. When the installation window is released, the progress is correctly displayed.
Regression range
- I will search for one ASAP if there is one.
- On Firefox 71 stub installer, the installation progress is correctly displayed while the installation window is moved around the screen.
Notes
- Attached a screen recording.
- This occurs for all the stub installer windows (install, reinstall, update).
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
|
||
As I understand it, the trouble here is that our message loop doesn't spin while a modal loop (in DefWindowProc or wherever) is handling the window move, see Raymond Chen's blog, so we stop becoming alertable. Our own ParentWndProc
is still being run to handle messages, though, so as an imperfect workaround we could add a MsgWaitForMultipleObjectsEx(0, nullptr, 0, 0, MWMO_ALERTABLE)
in there. This only gets a chance when the window has to deal with a message anyway, though.
We could have a dedicated thread for running the APC, but I don't think we want to deal with multithreading. Probably the most robust solution would be to use WM_TIMER
messages, which I think will always get handed through to our proc as needed. This will require tracking timer IDs, though, unless we decide to use a single timer at a time, which I think is what the stub is doing currently (and which is assumed given the single $TimerHandle
).
Comment 2•4 years ago
|
||
SetTimer's timers can be more reliably handled by a single window thread,
even when our own message loop isn't spinning, because WM_TIMER messages
are still being handled.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
The priority flag is not set for this bug.
:agashlin, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
Updated•3 years ago
|
Description
•