We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We currently extract Document pointers from the old LoadInfo, and attach them to the new one, such that they aren't lost during serialization.
This moves us to setting them more directly from their original source, since the old LoadInfo is no longer reliable (and was only configured fully in the parent process).
Differential Revision: https://phabricator.services.mozilla.com/D64249
--HG--
extra : moz-landing-system : lando
We currently extract Document pointers from the old LoadInfo, and attach them to the new one, such that they aren't lost during serialization.
This moves us to setting them more directly from their original source, since the old LoadInfo is no longer reliable (and was only configured fully in the parent process).
Differential Revision: https://phabricator.services.mozilla.com/D64249
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
This removes `nsAutoPtr` usage from ipc/. security/ failed to build due to missing includes so I fixed that as well. IDB was using `ThreadLocal` from ipc which had a member changed to a `UniquePtr` so needed to be updated as well. localstorage was missing some includes.
Differential Revision: https://phabricator.services.mozilla.com/D63745
--HG--
extra : moz-landing-system : lando
We want to be able to send IPC messages from the translation in the parent. So
the simplest thing it move the top level actor parts of CanvasParent into
CanvasTranslator.
This patch also moves the canvas thread management parts out into a new
CanvasThreadHolder class and hopefully makes the lifecycle management of these
much more robust. This includes the use of a TaskQueue per CanvasTranslator to
manage serial processing on the canvas workers, instead of a boolean.
Differential Revision: https://phabricator.services.mozilla.com/D60887
--HG--
rename : gfx/layers/ipc/CanvasParent.cpp => gfx/layers/ipc/CanvasThread.cpp
rename : gfx/layers/ipc/CanvasParent.h => gfx/layers/ipc/CanvasThread.h
rename : gfx/layers/CanvasTranslator.cpp => gfx/layers/ipc/CanvasTranslator.cpp
rename : gfx/layers/CanvasTranslator.h => gfx/layers/ipc/CanvasTranslator.h
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
Previously we passed a potentially NULL pointer to
CrashReporterHost::FinalizeOrphanedMinidump() which always assumed it to be
non-NULL. This patch solves the issue but preventing the pointer from being
NULL and making CrashReporterHost::GenerateCrashReport() infallible. In the
case we fail to take a minidump the only visible effect will be that the
minidump ID will be empty, and existing code already expects and handles this
scenario correctly.
Differential Revision: https://phabricator.services.mozilla.com/D63179
--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
Accessing StaticPrefs at xpcom-startup is too early to cause the
initialization of it. The preferences from user.js and profile are
not load yet. So, later, it would cause error of changing the value
of static prefs that is marked as mirroring once.
Differential Revision: https://phabricator.services.mozilla.com/D62866
--HG--
extra : moz-landing-system : lando
Apps targeting SDK 29 are not allowed to open /dev/ashmem directly, and
instead must use NDK functions. Those functions are only available in
SDK 26 and higher, so we need this shim to use the functions if they
are available, else fallback to opening /dev/ashmem directly.
Differential Revision: https://phabricator.services.mozilla.com/D61012
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando