Add option to EnsureMTA to forcibly dispatch events to its thread

RESOLVED FIXED in Firefox 68

Status

()

task
P1
normal
RESOLVED FIXED
a month ago
a month ago

People

(Reporter: aklotz, Assigned: aklotz)

Tracking

Trunk
mozilla68
Unspecified
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(1 attachment)

Assignee

Description

a month ago

In sandboxed processes with Win32k lockdown, when we initialize COM using an MTA on a background thread, the main thread is automatically initialized by the COM runtime as having an implicit MTA.

This is fine, except for the fact that if we want to enqueue any work that needs to operate specifically on the EnsureMTA thread, it won't happen.

We can add a flag to EnsureMTA's constructor that ensures that, even if the current thread is in an MTA (implicit or otherwise), we still forcibly enqueue the closure specifically to the EnsureMTA thread.

Assignee

Comment 1

a month ago

In sandboxed processes with Win32k lockdown, when we initialize COM using an MTA
on a background thread, the main thread is automatically initialized by the COM
runtime as having an implicit MTA.

This is fine, except for the fact that if we want to enqueue any work that needs
to operate specifically on the EnsureMTA thread, it won't happen.

This patch adds a flag to EnsureMTA's constructor that ensures that, even if the
current thread is in an MTA (implicit or otherwise), we still forcibly enqueue
the closure specifically to the EnsureMTA thread.

Comment 2

a month ago
Pushed by aklotz@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3e3a2ecafdaa
Add option to mscom::EnsureMTA to forcibly dispatch events to its thread; r=Jamie

Comment 3

a month ago
bugherder
Status: ASSIGNED → RESOLVED
Last Resolved: a month ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.