We cache this information in compatibility.ini so we can just expose it on
nsIXULRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D66112
--HG--
extra : moz-landing-system : lando
We cache this information in compatibility.ini so we can just expose it on
nsIXULRuntime.
Differential Revision: https://phabricator.services.mozilla.com/D66112
--HG--
extra : moz-landing-system : lando
To correctly implement this, it must be known on instantiation whether E is
copy-constructible, which is not the case if only a forward declaration is
available. This can be resolved either by making sure a full definition of E is
available, which is preferable. But in cases where this is not (easily) possible,
the information can be explicitly provided by the MOZ_DECLARE_COPY_CONSTRUCTIBLE
and MOZ_DECLARE_NON_COPY_CONSTRUCTIBLE macros. In particular, declarations for
IPDL-declared types are added to nsTArray.h itself, like it was already done
for MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR.
Differential Revision: https://phabricator.services.mozilla.com/D66244
--HG--
extra : moz-landing-system : lando
Specifically, this renames
* nsTArray_CopyChooser to nsTArray_RelocationStrategy
* the Copy template argument of nsTArray_base to RelocationStrategy
* nsTArray_CopyWithConstructors to nsTArray_RelocateUsingMoveConstructor
* nsTArray_CopyWithMemutils to nsTArray_RelocateUsingMemutils
* DECLARE_USE_COPY_CONSTRUCTORS to MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR
Differential Revision: https://phabricator.services.mozilla.com/D66243
--HG--
extra : moz-landing-system : lando
This works on all platforms with the exception of Linux where we remove the
exception handler only if the sandbox is disabled. With the sandbox enabled we
would have to whitelist sigaltstack() which breakpad uses to remove the
alternate signal stack which is not worth the fuss.
Besides this patch refactors the code that sets and unsets the exception
handler, cutting down on the duplication:
* The XRE_UnsetRemoteExceptionHandler() call is removed from XULAppAPI.h since it
was no longer used
* The duplicate checks for the special strings used to disable the remote exception
handler have been removed from CrashReporter::UnsetRemoteExceptionHandler()
leaving them in the calling code
* The SetRemoteExceptionHandler() function was consolidated into only one
piece of code with only one non-platform-specific shared prototype
* Some additional code was factored out to improve the readability
These changes pave the way both for bug 1614933 and for the oxidation of the
exception handler code.
Differential Revision: https://phabricator.services.mozilla.com/D67213
--HG--
extra : moz-landing-system : lando
- Do not remove elements one-by-one but use remove-erase pattern.
- Move mPendingIDBTransactions array instead of copying.
Differential Revision: https://phabricator.services.mozilla.com/D67159
--HG--
extra : moz-landing-system : lando
Ply doesn't actually support python3. The generation of the files seems
to work with python3 for some reason, but running the corresponding
tests doesn't. The only version of ply that supports python3 is
currently in beta, so upgrading ply is probably not an option at the
moment.
Other commands that do use ply (mach webidl-parser-test and
ipc/ipdl/Makefile.in) have not switched to python3 (probably because
they don't work). Let's go with the simpler thing for now: switch back
to python 2 for xpidllex.py and xpidlyacc.py, which will make them
deterministically created again.
Differential Revision: https://phabricator.services.mozilla.com/D67400
--HG--
extra : moz-landing-system : lando
This never worked, but it's more visible with the new form controls which have
more padding.
Make the anonymous div and co a pseudo-element, so that they inherit from the
<input> properly in all cases. This works for non-number inputs because the
editor root is a direct child of the <input>, but it doesn't for number inputs
because there's a flex wrapper in between.
This way overflow-clip-box: inherit does what we want. Reset the padding in the
inline direction, as the padding for <input type=number> applies to the arrow
boxes as well, and thus we'd double-apply it.
Differential Revision: https://phabricator.services.mozilla.com/D65271
--HG--
extra : moz-landing-system : lando
There's no existing macro to allow use declare a final
DeleteCycleCollectable, this patch adds one
Differential Revision: https://phabricator.services.mozilla.com/D63262
--HG--
extra : moz-landing-system : lando
This commit moves `NS_CreateBackgroundTaskQueue` into an `extern "C"`
block, adds a `create_background_task_queue` function to `moz_task`,
and makes it possible to dispatch Rust `TaskRunnable`s to any event
target, instead of just an `nsIThread`.
Differential Revision: https://phabricator.services.mozilla.com/D66700
--HG--
extra : moz-landing-system : lando
This is one of the efforts to reduce usage of `ShellExecuteByExplorer`
(bug 1620335).
The purpose of using `ShellExecuteByExplorer` in the scenario to open a
downloaded file is to support applications which are not compatible with
the mitigation policies of our process. When a downloaded file is an
executable, however, we prefer security to compatibility and in particular
we want to prevent binary planting on a user's download directory.
The proposed fix is to go to `ShellExecuteExW` straight if the target
file to launch is an executable.
Differential Revision: https://phabricator.services.mozilla.com/D66325
--HG--
extra : moz-landing-system : lando
This is one of the efforts to reduce usage of `ShellExecuteByExplorer`
(bug 1620335).
The purpose of using `ShellExecuteByExplorer` in the scenario to open a
downloaded file is to support applications which are not compatible with
the mitigation policies of our process. When a downloaded file is an
executable, however, we prefer security to compatibility and in particular
we want to prevent binary planting on a user's download directory.
The proposed fix is to go to `ShellExecuteExW` straight if the target
file to launch is an executable.
Differential Revision: https://phabricator.services.mozilla.com/D66325
--HG--
extra : moz-landing-system : lando
BrowserTestUtils.crashFrame now accepts additional `options`, with an argument `crashType` that may
take "CRASH_OOM" or "CRASH_INVALID_POINTER_DEREF"|null to specify the nature of the crash. The names
are taken from CrashTestUtils.jsm but this module cannot be imported as such as it has non-trivial
binary dependencies.
Depends on D54130
Differential Revision: https://phabricator.services.mozilla.com/D54700
--HG--
extra : moz-landing-system : lando
Right now, we sync finalize for a sync GC, even if it is triggered by the JS
engine itself. This can cause issues because the finalizer can run JS, which
can break assumptions made by the JIT.
This patch avoids that by running the finalizers incrementally for most internal
GC triggers. We still run sync for DESTROY_RUNTIME because we're going to shut
down right away.
Differential Revision: https://phabricator.services.mozilla.com/D65649
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
This is already done for the outer nsJAR, but it wasn't done for the inner nsJAR.
(The omnijar is a nested zip archive on Android: the outer archive is the APK and the inner is the omnijar file.)
So we were re-using the file mapping but not the result of the uncompression.
Differential Revision: https://phabricator.services.mozilla.com/D63970
--HG--
extra : moz-landing-system : lando
Idle runnables do weird things involving unlocking the event queue mutex while
looking for runnables, such that queueing one from off the main thread might
cause it to basically never run if it gets queued during one of those
temporary-unlock periods.
Differential Revision: https://phabricator.services.mozilla.com/D65019
--HG--
extra : moz-landing-system : lando
Note that perfecthash.py is also used by other scripts, so it needs to
remain py2 compatible for now.
Differential Revision: https://phabricator.services.mozilla.com/D64620
--HG--
extra : moz-landing-system : lando
