This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
HookProtectedMode requires its nsWindowsDllInterceptor to last as long as the functions need to be overridden. This uses a static object instead of a local one.
--HG--
extra : rebase_source : 7ba3f2fc1e19f89936b7f7fa490554e9cf9b885c
The camera is blocked by the sandbox hardening in part 1. This intercepts and remotes the call to CreateMutexW that causes the camera to fail.
--HG--
extra : rebase_source : 8431b9c5b4e2ca35590692e0c71e68900b7f75b1
Previously, all FunctionBrokers used the same global set of type marshalers to handle IPC. The marshaling behavior is endpoint-dependent so it is done with the EndpointHandler. This patch makes the EndpointHandler used by a specific RPC function into a template parameter to the function's FunctionBroker. It also divides up the current special type handling into two cases -- FileDlgEndpointHandler for plugin file dialog brokering, and SslEndpointHandler for SSL communication brokering.
--HG--
extra : rebase_source : 160abbc77a202b752dd41655980745e770c6b915
Level 3 changes the plugin process access token from USER_INTERACTIVE to USER_LIMITED.
--HG--
extra : rebase_source : 0a037adf08e4f729bd9e129203f5c403cfc12f4b
We'll start to dispatch keydown event and keyup event even during composition.
So, for testing those events won't break our UI, we should make
EventUtils.synhtesizeComposition() and EventUtils.synthesizeCompositionChange()
dispatch keydown event and keyup event even if callers don't specify keyboard
event explicitly.
Typically, "keydown" event is marked as "processed by IME", i.e., keyCode
value is set to DOM_VK_PROCESSKEY and key is set to "Process", with our
widget which handles native IME and key input. On the other hand, "keyup"
is NOT marked as so.
Therefore, this patch makes TextInputProcessor emulates this behavior without
any new special flags. And for making possible to emulate special cases,
this patch adds two flags to nsITextInputProcessor. One is
KEY_DONT_MARK_KEYDOWN_AS_PROCESSED. The other is KEY_MARK_KEYUP_AS_PROCESSED.
Unfortunately, those flags have opposite meaning but this must be better than
making necessary to one flag for emulating usual keydown/keyup events.
Finally, this makes some tests specify better keyboard information to
synthesizeComposition() and synthesizeCompositionChange() to emulate
actual keyboard events during composition.
MozReview-Commit-ID: ItYaXILkNQE
--HG--
extra : rebase_source : e50cc77c1efbc12686d7ea334d41926c7392b30d
Replace the boolean pref "security.sandbox.mac.flash.enabled"
with "dom.ipc.plugins.sandbox-level.flash" to support sandbox
levels and be consistent with the Windows pref name.
Adds filesystem read access to the sandbox using sandbox extensions
granted by the file dialog machinery (level 1).
Add support for level 2 which blocks read access.
Allow the sandbox to be disabled with MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 4rfobEoxQpF
--HG--
extra : rebase_source : 05dc54b46063967e959bc3fced21c61e5463de48
Replace the boolean pref "security.sandbox.mac.flash.enabled"
with "dom.ipc.plugins.sandbox-level.flash" to support sandbox
levels and be consistent with the Windows pref name.
Adds filesystem read access to the sandbox using sandbox extensions
granted by the file dialog machinery (level 1).
Add support for level 2 which blocks read access.
Allow the sandbox to be disabled with MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 4rfobEoxQpF
--HG--
extra : rebase_source : 87f2f00867c4522ae3102abbc44fd05db63c7ec7
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