This changes the pluginreg.dat format to include the blocklist state.
There is now only the saved blocklist state in a plugin tag instance, rather than
looking it up from in there using the blocklist service, so it was renamed from
mCachedBlocklistState to mBlocklistState. We pass the 'right' state to the plugin
instance when the plugintag is constructed. If we don't have state, we mark it as
unblocked.
mCachedBlocklistStateChanged was never read so it's being removed.
Bug 1439519 adds a 'blocklist-loaded' notification that is fired once the blocklist is loaded.
The plugin host implementation will listen to this in the parent process and update the
blocklist state of all the plugins, and broadcast changes to the child process, just like when
we update the blocklist from the server. We now also avoid re-sending plugin content to the
content processes if the plugin state hasn't changed as a result of the blocklist having been
loaded.
Finally, because new plugins should still get an up-to-date blocklist state, and
telemetry should get up-to-date data about which plugins are and aren't enabled
once we have that data, we ensure that once we've loaded the blocklist async,
we schedule an idle task to parse it and consider it loaded.
All this means that plugin blocklist information could be mistaken between the points where
a new plugin is installed and we first run Firefox with the new plugin, and the point where
we load the blocklist. Given the trade-offs, that size of window (tiny) seems OK, also given
that there's already a much larger window in blocklist updates (which only happen once every 24h).
MozReview-Commit-ID: 1gsojRkUzTw
--HG--
extra : rebase_source : 4709916b4674ada54f8a495fd2d16fcef8c58d20
Removing #define XRE_DONT_PROTECT_DLL_LOAD from plugin-container.cpp and xpcshell.cpp allows the #included nsWindowsWMain.cpp to protect DLL loads much earlier in the plugin process startup.
MozReview-Commit-ID: HbgyfvljvFs
--HG--
extra : rebase_source : dccdabb2e5bee4472d5aef9400a58cb0e397c112
extra : histedit_source : da248fc6fbdf96f30979f3a0396aefcf4bfcd5d9
This code was added in bug 607832 to work around a Shockwave Player bug where it tries to load some DLLs from the current directory, but the current directory is not the one it expects. We no longer support the Shockwave Player plugin, so this workaround is no longer necessary and we can always call SetDllDirectory("") to remove the current directory from the DLL search path.
MozReview-Commit-ID: C4MjB1SkZE3
--HG--
extra : rebase_source : 6473ca88db6bee484c3c97669dca39daf31b438e
extra : histedit_source : f4abb901979b07f0aa346508773a8e65f47451cd
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
The Monitor's Wait call is subject to spurious waking and needed a condition guard (I just use a boolean) to detect if it should not have been awakened. Additionally, the ok value was being assigned after the Notify, despite it no longer being valid on this thread.
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
CleanupFromTimeout is (transitively) recursing in calls to Close(), as that now leads to shutting down the plugin broker thread and CleanupFromTimeout was being rerun since nsThread::Shutdown runs tasks..
The Monitor's condition variable could be notified before the calling thread had begun to Wait for it. This caused the Notify to be missed, leading to hangs. By grabbing the Monitor in PostToDispatchHelper, we know Wait has been called because, otherwise, the calling thread would still hold the Monitor.
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Includes the build changes made by the earlier patches in this series. Also adds some #includes required by other files when these are added to the unified build.
The FunctionBroker is a special kind of FunctionHook that brokers the hooked function on another process. In the child process, it uses the FunctionBrokerChild to request that the FunctionBrokerParent run a function and return the response. It handles most cases of parameter, return value and error marshaling on its own. It also guarantees that requests are issued from the proper thread.
The FunctionBroker actors allow the NPAPI process (child) to run methods on the main process (parent). Both the parent and the child run dedicated threads for this task -- this is a top-level protocol.
IpdlTuple is an array of Variants that is accessed by type and that reports an error if there is a type error. This is used for safe and easy communication of IPDL objects, validated at run time since IPC data is untrusted.
We have not been initializing or shutting down XPCOM in the plugin process. We need the nsThreadManager for this bug but, more importantly, we need to properly shut down XPCOM in order to get things like handlers connected to the ShutdownPhases (e.g. ClearOnShutdown, used to free resources at process end).
This patch includes some work to make services that are uninitialized in the plugin process to handle Shutdown calls without failing.
The shutdown path has a way to free the sObjectMap before all plugin references to it have been executed. It does this by scheduling a DeferNPObjectReleaseRunnable, then shutting down the plugin with PluginInstanceChild::Destroy. This patch keeps the runnable from failing in that case.
This is a follow-up to bug 1409249. There are a lot of places where our
factory singleton constructors either don't correctly handle their returned
references being released by the component manager, or do handle it, but in
ways that are not obvious.
This patch handles a few places where we can sometimes wind up with dangling
singleton pointers, adds some explanatory comments and sanity check
assertions, and replaces some uses of manual refcounting with StaticRefPtr and
ClearOnShutdown.
There are still some places where we may wind up with odd behavior if the
first QI for a getService call fails. In those cases, we wind up destroying
the first instance of a service that we create, and re-creating a new one
later.
MozReview-Commit-ID: ANYndvd7aZx
--HG--
extra : rebase_source : acfb0611a028fef6b9387eb5d1d9e285782fbc7c
The sNPObjWrappers table can contain entries for dead JSObjects that have not yet been finalised. We need to take care not to trigger mJSObj's read barrier for such entries since that will attempt to expose the object to JS and cause this assertion.
The patch does this by calling unbarrieredGetPtr() which avoids the barrier.
Note converting a TenuredHeap to bool and testing equality against a pointer don't trigger the barrier.