Open Bug 1632768 Opened 4 years ago Updated 3 years ago

Installer Progress Bar is stuck while the installation window is moved around the screen

Categories

(Firefox :: Installer, defect, P2)

77 Branch
Desktop
Windows
defect

Tracking

()

Tracking Status
firefox77 --- affected

People

(Reporter: cbadau, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

Attached image issue.gif

Affected versions

  • 77.0a1 (20200423214309)

Affected platforms

  • Windows 10 x64
  • Windows 8.1 x64

Steps to reproduce

  1. Download and run the Stub Installer.
  2. 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).
Blocks: 1632191
Assignee: nobody → agashlin
Has Regression Range: --- → no
Has STR: --- → yes

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).

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.

Attachment #9143838 - Attachment is obsolete: true

The priority flag is not set for this bug.
:agashlin, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(agashlin)
Severity: normal → S4
Flags: needinfo?(agashlin)
Priority: -- → P2
Assignee: agashlin → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: