This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
The default method implementations cause problems when trying to
override them with different types in a direct call class.
For the `Recv__delete__` case there's a simple solution: omit it if
there are any arguments, because it doesn't make much sense to specify
arguments and then completely ignore them, and the no-arg case isn't a
problem for overriding.
Differential Revision: https://phabricator.services.mozilla.com/D62977
--HG--
extra : moz-landing-system : lando
This also adds an explicit warning when this happens so that the child processes don't crash without leaving a trace.
Differential Revision: https://phabricator.services.mozilla.com/D60650
--HG--
extra : moz-landing-system : lando
When a content or plug-in process crashes too early we haven't initialized the
CrashReporterHost for that process. This will cause the crash to be orphaned,
i.e. to miss most of its crash annotations. We added code to finalize those
crashes in bug 1282776 so that we wouldn't miss them entirely. This ensured
that crash reports would have both their .dmp and .extra files but the patch
failed to modify the code that notified various listeners about the crash
report's presence.
This changes always send the crash ID alongside the crash notifications, even
for orphaned crashes, so that listeners such as the content crash handler or
the test harnesses can always find the minidump and .extra file. Additionally
orphaned crashes are recorded in the CrashManager and in telemetry just like
normal crashes.
This also re-enables dom/ipc/tests/process_error.xul which failed frequently
because of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D57634
--HG--
extra : moz-landing-system : lando
foo ? true : false
or:
foo ? false : true
Have always a nicer way to be written.
Differential Revision: https://phabricator.services.mozilla.com/D56842
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
This patch adds a new field to the `plugin-crashed` event that holds the list
of additional minidumps associated with a crash report. The test
infrastructure is modified to use it which also fixes a race when processing
the .extra file. The reftest machinery has also been modified to take the new
field into account.
Differential Revision: https://phabricator.services.mozilla.com/D54107
--HG--
extra : moz-landing-system : lando
Previously, we created TextureD3D11 objects in the content process to back surfaces created for the plugin process. Those objects were then composited by the async ImageBridge. In order to remove Win32 kernel operations from content (including DX/GDI operations), this patch bounces the requests from content to the compositor process. The compositor process maintains 2 textures to be used for all plugin composition -- one for the plugin process and one for display. The plugin process can freely write to its texture and request composition when it is done, which triggers a blit to the display texture. This mirrors pre-existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D46086
--HG--
extra : moz-landing-system : lando
These operations report whether certain async plugin drawing modes are supported on the host architecture. They use kernel graphics operations to decide this so they need to be removed from the content process for sandboxing. We just bounce the requests to the gpu process (or main process on systems without a GPU process).
Differential Revision: https://phabricator.services.mozilla.com/D46085
--HG--
extra : moz-landing-system : lando
Use this pref to disable NPDrawingModelAsyncWindowsDXGISurface mode, which will force compatible plugins (Flash) to use NPDrawingModelAsyncBitmapSurface.
Differential Revision: https://phabricator.services.mozilla.com/D46084
--HG--
extra : moz-landing-system : lando
This fallback drawing mode primarily uses in-memory textures in the content process (via Readback) but uses gfxPlatform to establish the GPU texture type. On Windows, this is always Win32 so we can avoid the gfxPlatform call (which uses Win32k heavily). I believe that this removes all Win32 operations involved in this drawing mode in a content process.
Differential Revision: https://phabricator.services.mozilla.com/D46083
--HG--
extra : moz-landing-system : lando
Properly handles NPError reporting and makes sure that, in the case of failure, it does not return junk for the NPObject.
Differential Revision: https://phabricator.services.mozilla.com/D48474
--HG--
extra : moz-landing-system : lando
By storing the plugin information in prefs when only flash is allowed, we can
avoid reading pluginreg and doing a plugin scan on the mainthread on startup.
As part of this, we're now keeping track of the 'is flash allowed' pref on the
plugin host, and no longer write 'valid' plugin info into pluginreg if so.
Also note that in this commit, we're changing `mPluginRegFile` to actually
refer to the file, rather than the containing directory.
Differential Revision: https://phabricator.services.mozilla.com/D48328
--HG--
extra : moz-landing-system : lando
By storing the plugin information in prefs when only flash is allowed, we can
avoid reading pluginreg and doing a plugin scan on the mainthread on startup.
As part of this, we're now keeping track of the 'is flash allowed' pref on the
plugin host, and no longer write 'valid' plugin info into pluginreg if so.
Also note that in this commit, we're changing `mPluginRegFile` to actually
refer to the file, rather than the containing directory.
Differential Revision: https://phabricator.services.mozilla.com/D48328
--HG--
extra : moz-landing-system : lando
Lots of these callbacks have a non-`void*` final parameter, which UBSAN
complains about. This commit changes them to have a `void*` parameter.
This requires undoing the machinery added in the first two commits of bug
1473631: `TypePrefChangeFunc` and `PREF_CHANGE_METHOD`. The resulting code is
simpler (which is good) and more boilerplate-y (which is bad) but avoids the
undefined behaviour (which is good).
Differential Revision: https://phabricator.services.mozilla.com/D50901
--HG--
extra : moz-landing-system : lando
As part of sandboxing the content process for Windows, we want to remove these calls from it. These instances of GetKeyState should not be in actual use since plugin mouse events are handled through different means. When they come to nsPluginInstanceOwner::ProcessEvent, they come with a pre-filled-in mPluginEvent, and this code is conditional on that not happening. Despite that, I am preserving the existing behavior by moving the GetKeyState calls to the plugin process (where they are brokered to the parent process). This fix is more robust to change than just removing the code would be.
Differential Revision: https://phabricator.services.mozilla.com/D47937
--HG--
extra : moz-landing-system : lando
GetForegroundWindow in PluginInstanceParent is used as part of message throttling in windowed plugins -- which we no longer officially support. We need to remove it from normal behavior for sandboxing the content process as part of win32k-lockdown. We are not removing windowed plugin code yet so, rather than break the behavior, I've gated the win32 calls so that they aren't run with windowless plugins.
Note that the original behavior was fine as the sandbox just makes the function return NULL -- but it would still show up in stack analysis so the behavior in this patch is preferred.
Differential Revision: https://phabricator.services.mozilla.com/D47936
--HG--
extra : moz-landing-system : lando
This changes the way crash reports for child processes happening too early
during the child process' startup. Before bug 1547698 we wrote a partial
.extra file with those crashes that lacked the process type. The user would
not be notified of those crashes until she restarted Firefox and even when
submitted those crashes would be erroneously labeled as browser crashes.
After bug 1547698 we stopped writing .extra files entirely for those crashes
which left orphaned .dmp files among the pending crash reports.
This patch does three things to improve the situation:
* It writes a partial .extra file so that the crashes are detected at the next
startup. So the user is still not notified directly of these crashes but she
can report them later.
* It adds the process type to the .extra file so that the crash reporters are
labelled correctly.
* It fixes a leak in the `pidToMinidump` hash-map. Since the crashes were
not finalized the `ChildProcessData` strucutre associated with them would
never be fred.
Differential Revision: https://phabricator.services.mozilla.com/D40810
--HG--
extra : moz-landing-system : lando
The patch also removes the dom.vr.oculus.quit.timeout pref, because it's
unused.
Differential Revision: https://phabricator.services.mozilla.com/D35973
--HG--
extra : rebase_source : bd16ed5ff0b7c2b4f8e653e9835610b25b14a39f
gfxPlatform::GetSourceSurfaceForSurface and CreateDrawTargetForSurface
are both static methods that we sometimes use via the pattern
gfxPlatform::GetPlatform()->... This is problematic because this forces
gfxPlatform to be initialized in the process, and in the GPU process, we
don't support this. It should be safe to call these methods without
initializing gfxPlatform, so this patch removes the GetPlatform() call.
GetSourceSurfaceForSurface may end up initializing gfxPlatform anyways,
depending on whether or not a DrawTarget was given. This should not be a
concern for the crashes observed in bug 1435586.
Differential Revision: https://phabricator.services.mozilla.com/D33785
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
Only gtk returns failure ever, and nobody checks the result anyway.
Use an enum class so that it's clear from the caller what it means.
Differential Revision: https://phabricator.services.mozilla.com/D32353
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This allows for the getter to be used in IProtocol's destructor, and generally
brings IProtocol more in line with IToplevelProtocol.
Differential Revision: https://phabricator.services.mozilla.com/D32042
--HG--
extra : moz-landing-system : lando