The `stack` slot of an `ErrorObject` can be a cross-compartment wrapper
and it can get nuked. Callers usually don't expect these proxies so check
for this in `ErrorObject::stack`.
Differential Revision: https://phabricator.services.mozilla.com/D200910
This patch is the result of running:
> ./mach python python/mozbuild/mozbuild/gn_processor.py \
> dom/media/webrtc/third_party_build/gn-configs/webrtc.json
Differential Revision: https://phabricator.services.mozilla.com/D200118
Side-effects when converting the input value can resize the TypedArray, so
that a previously non-existent property is now in-bounds.
Differential Revision: https://phabricator.services.mozilla.com/D200636
`nsIFrame::GetCursor()` can never return `Nothing()` after bug 1687239, which
removes `nsPluginFrame`. Therefore `mLastFrameConsumedSetCursor` in
`EventStateManager` can never be true.
Differential Revision: https://phabricator.services.mozilla.com/D200890
Currently there is a per-process task limit to the number of GC parallel tasks
that can run at once (different and usually smaller that the total number of
helper thread tasks that can run). If multiple runtimes are collecting they can
starve each other of tasks even when there are helper threads spare.
This moves the limit from per-process to per-runtime and allows us to run as
many GC parallel tasks in total as there are helper threads.
A new state is added for GC parallel tasks to indicate they are queued on the
runtime before they have been dispatched to the helper thread system.
Differential Revision: https://phabricator.services.mozilla.com/D200824
The assertion is failing beacuse the number of slots allocated (zero) doesn't
match the number we expect given the object's shape. Since allocation is
failing and the object will be unreachable, the patch sets the shape to that of
a plain object with zero slots. This should be a safe default.
We have to also ensure that this shape always exists so we can allocate it when
the global is initialized.
This means we can also remove the workaround fix for bug 1828396.
The patch also fixes DumpHeap so it doesn't try and flcose a null file handle,
which crashes on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D200675
Fixes code to properly run tests with the feature enabled.
Fixes code not considering payload.userContextId is set to -1 for private
windows.
Fixes a bug in the _openTabs Map where multiple open tabs to the same url are
not properly counted.
Differential Revision: https://phabricator.services.mozilla.com/D200036
These rules are node specific and not really useful in mozilla central:
handle-callback-err, no-buffer-constructor, no-path-concat, no-process-exit
These rules are not useful as require is only used in configurations:
no-new-require, no-mixed-requires
Prettier already enforces max-statements-per-line
lines-between-class-members isn't handled separately, but if we want to do that we should decide on it globally.
Differential Revision: https://phabricator.services.mozilla.com/D200588
These loops may run script.
In `HyperTextAccessible`, it calls
`RemoveRangeAndUnselectFramesAndNotifyListeners`. So, chrome script which is not
directly related to this module may run in each call. I think that using
`RemoveAllRanges` is better for here. Before bug 1735446, this loop tried
to keep first range, but accidentally, I changed this loop delete all ranges.
However, `SetSelectionBoundsAt` will add a range if it's required and there is
no bug reports. Therefore, I think keep the new behavior is better.
In `nsRange::DeleteFromDocument`, the loop may run mutation events too.
Therefore, it needs to store all ranges first. Then, the preceding patch
changes the behavior here if a selection range is moved to different root.
Previously, it was deleted, but now, they are not touched.
Depends on D200606
Differential Revision: https://phabricator.services.mozilla.com/D200607
Users of `Selection` assume that `nsRange` instances are ranges in the
corresponding document. However, `Selection` may keep storing ranges in
the different root only when the range is updated. I think that no spec
defines this behavior, but Chromium makes `RangeUpdateScope` delete ranges
which are in different root after the range is updated [1]. Let's follow
this behavior for compatibility and keeping the assumption of `Selection`
users.
Differential Revision: https://phabricator.services.mozilla.com/D200606
