Open Bug 1925415 Opened 1 year ago Updated 1 year ago

Remove manual COM initialization in nsWindowsShellService

Categories

(Firefox :: Shell Integration, defect, P3)

defect

Tracking

()

People

(Reporter: nrishel, Assigned: nrishel)

References

Details

(Whiteboard: [fidedi])

Predating ITaskbarManager being made available to Win32 applications, we used an undocumented IPinnedList3 COM API to pin to taskbar. We retain that code for pinning on outdated Windows installs.

The TaskbandPin object implementing IPinnedList3 has STA thread affinity and does not implement marshaling, therefore we can't retrieve the IPinnedList3 interface from an MTA thread, see Why do I get E_NOINTERFACE when creating an object that supports that interface?. All of our threads except the main thread are implicit MTA threads, and pooled threads such as those used with NS_DispatchBackgroundTask should remain such. When we made our pinning code async, we broke this contract by initializing the background task thread to a STA.

This pattern was unnecessarily repeated for other async migrations in nsWindowsShellService; only the IPinnedList3 seems to fail among the code paths investigated when removing CoInitialize.

Taskbar pinning was made async to remove IO on the main thread to determine if the app is pinned, which is called during startup and through the same interface as actually pinning. The easiest solution which removes manual COM initialization is to move IPinnedList3 calls to the main thread (and avoid managing our own thread and COM initialization) similar to usages of ITaskbarManager. Pinning itself is an irregular path and the concerns associated with shortcut iterating don't apply.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.