Closed Bug 1119060 Opened 10 years ago Closed 10 years ago

PluginProcessParent's pointer to its LaunchRunnable must remain non-null until the runnable has executed

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows 8.1
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla37

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

Attachments

(1 file)

Otherwise things behave badly if we want to do a WaitUntilConnected when the runnable is already queued up to the main thread message_loop.
Attached patch FixSplinter Review
Attachment #8545559 - Flags: review?(gfritzsche)
The problem is as follows: When we are forced to wait synchronously for plugin initialization (for example a script is querying for a property), we might need to wait for the plugin container to launch. Normally the runnable would be enqueued to the main thread and would eventually execute. Unfortunately in this scenario. That won't work in this case because the main thread must block until the plugin has launched, so in this case we execute the runnable immediately. Without this patch, we could have a scenario where the process launch runnable would be enqueued to the main thread and PluginProcessParent::mLaunchCompleteRunnable is then set to nullptr. When the main thread tries to execute the runnable immediately, it sees a null runnable (which is incorrect), does not finish setting up the plugin process, and then tries to do stuff with the plugin. This fix ensures that the runnable pointer is non-null until it executes either immediately or from the main thread message loop.
(Ignore the "Unfortunately in this scenario.")
Attachment #8545559 - Flags: review?(gfritzsche) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: