I'd like to use a nsTHashtable acting as a set in a struct that will be passed over IPDL, but
couldn't find any ParamTraits implementation for it. It'd be nice to make the implementation
generic, but I couldn't find an easy way to do it.
Differential Revision: https://phabricator.services.mozilla.com/D6782
--HG--
extra : rebase_source : f22b788d99cc336867871d2c89919fc8ddec2371
I'd like to use a struct over IPDL which is move only. This patch adds a modifier to
usings statements to indicate the C++ type should always be moved, similar to refcounted.
Differential Revision: https://phabricator.services.mozilla.com/D6781
--HG--
extra : rebase_source : 492309e2ec4f4cc6a6ffe639e3c6e4adfb6ecf08
The only consumer of this code was Singleton, which we previously
removed, and everything that this code accomplished can be done more
simply and more foolproof-y by standard constructs these days.
This patch allows IPDL tests to compile -- in other words, it fixes the build when the --enable-ipdl-tests flag is present. Most of the fixes are simple API updates but we also needed to fix an issue with the constness of nsTArray<Shmem> parameters that are defined in IPDL structs.
This patch does not fix the tests themselves -- some IPDL tests will still fail when run.
Differential Revision: https://phabricator.services.mozilla.com/D6705
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command
line allowing for early sandbox startup. Limited to Nightly
until confirmed to be stable and ready to ride the trains.
Enable early sandbox startup by default on Nightly and use
pref "security.sandbox.content.mac.earlyinit" to disable
early startup for debugging purposes.
Once early startup is stable, the original sandbox startup
code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
In Bug 1114647 we added this define, and it was used in ipc/contentproc/plugin-container.cpp
However its use there was removed as part of MOZ_PLUGIN_CONTAINER
Differential Revision: https://phabricator.services.mozilla.com/D7155
--HG--
extra : moz-landing-system : lando
The test used to assume that the load event didn't matter and so
the expected values had to be updated to match the new behavior.
A new "slowIFrame" test was added to capture what was previously
tested by the "badIFrame".
Differential Revision: https://phabricator.services.mozilla.com/D7031
--HG--
extra : moz-landing-system : lando
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
extra : intermediate-source : 5152af6ab3e399216ef6db8f060c257b2ffbd330
extra : histedit_source : ef06000344416e0919f536d5720fa979d2d29c66%2C4671676b613dc3e3ec762edf5d72a2ffbe6fca3f
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : fcf8fa50e748c4b54c3bb1997575d9ffd4cbaae1
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : 02c5572b92ee48c11697d90941336e10c03d49cf
As the comments indicate, it has unavoidable race conditions in a
multithreaded program, and its call sites have all been removed.
Differential Revision: https://phabricator.services.mozilla.com/D6561
--HG--
extra : moz-landing-system : lando
Add the first version of the IPDL-JS API, which allow chrome JS to load IPDL files and use them to communicate accross Content processes.
See IPDLProtocol.h for more information regarding how to use the API.
Differential Revision: https://phabricator.services.mozilla.com/D2116
--HG--
rename : ipc/moz.build => ipc/ipdl_new/moz.build
extra : moz-landing-system : lando
This change is mainly to avoid the use of SetAllFDsToCloseOnExec, which
has an unavoidable race condition that can leak file descriptors into
child processes. The "Linux" implementation of child process creation,
now that B2G support has been removed, is essentially a generic Unix
fork+dup2+execve which works on BSD (and is already used on Solaris).
This reverts the changes in bug 1360308, bug 1390143 and bug 1469603. Minidump
generation will now only happen on the main process' main thread which might
lead to hangs but is known to be fairly robust. Asynchronous generation proved
too brittle and enormously increased the complexity of this already
hard-to-read code.
Differential Revision: https://phabricator.services.mozilla.com/D5147
--HG--
extra : moz-landing-system : lando
The framework to simulate the setting change works as following;
- nsIDOMWindowUtils.setPrefersReducedMotion() calls an IPC function which ends
up calling nsChildView::SetPrefersReducedMotion() in the parent process
- nsChildView::SetPrefersReducedMotion() sets the given value into
nsLookAndFeel::mPrefersReducedMotionCached just like we set the value queried
via NSWorkspace.accessibilityDisplayShouldReduceMotion in the parent process
and send a notification which is the same notification MacOSX sends when the
system setting changed
- Normally the cached value is cleared before quering new values since the
cache value is stale, but in this case the value is up-to-date one, so
nsChildView::SetPrefersReducedMotion() tells that we don't need to clear the
cache, and nsIDOMWindowUtils.resetPrefersReducedMotion() resets that state
of 'we don't need to clear the cache'
There are two test cases with the framework in this commit, one is just setting
the value and checking the value queried by window.matchMedia. The other one is
receiving 'change' event and checking the value of the event target.
Note that to make this test works the patch for bug 1478212 is necessary since
the test runs in an iframe.
Depends on D5003
Differential Revision: https://phabricator.services.mozilla.com/D5004
--HG--
extra : moz-landing-system : lando
This patch adds the definitions of the RefPtr constructor and operator=.
It also refactors some stuff in AgileReference to make these objects easier
to use. Since it's just a bunch of C++ goop, I figured that you'd be fine to
review this. Let me know if you want to add a reviewer who is more familiar
with the COM nuances.
Depends on D5317
Differential Revision: https://phabricator.services.mozilla.com/D5318
--HG--
extra : moz-landing-system : lando
Several source files use DLL_PREFIX/DLL_SUFFIX defines, and they all set
them in moz.build using `DEFINES`. This is problematic for the WSL
build because the quoting gets lost somewhere between bash and cl.exe.
We cannot simply set them globally in moz.configure because their
stringified definitions would conflict with the `set_config` of
DLL_PREFIX/DLL_SUFFIX. Therefore, we globally define
MOZ_DLL_PREFIX/MOZ_DLL_SUFFIX and change all define-related uses of
DLL_PREFIX/DLL_SUFFIX to use their MOZ-equivalents instead.
This is the only reason I haven't used it before for things like
StyleSheet::State.
Change the underlying type to be the underlying enum representation by default,
but allow to override it if wanted.
Assertions should catch misuses.
Differential Revision: https://phabricator.services.mozilla.com/D5248
--HG--
extra : moz-landing-system : lando
