This environment variable can cause the module resolution to break
and have unexpected behavior while running mach bootstrap.
Differential Revision: https://phabricator.services.mozilla.com/D95185
This patch uses (and somewhat abuses) the existing PromiseTestUtils
mechanism to also be able to whitelist uncaught errors that are not
actual Promise rejections.
This uses `ChromeUtils.recentJSDevError`, which lets us find out
whether there is a recent ReferenceError/SyntaxError/TypeError in
chrome code, even if that error was caught.
MozReview-Commit-ID: 5z1pffURNYm
Differential Revision: https://phabricator.services.mozilla.com/D94972
This patch is part of an ongoing work to help our test suite show developer errors that are currently being swallowed by `try { ... } catch (e) { ... }`.
Previous patches in the work used the heuristic that all instances of `TypeError`, `SyntaxError` and `ReferenceError` are developer errors unless specified otherwise. As it turns out, we are throwing `TypeError` in many cases that are not type errors. Since we have no manner of distinguishing which of these cases are actual (developer) errors and which are runtime exceptions, this patch removes `TypeError` from the list of developer errors.
Ideally, a followup patch would carefully reactivate `TypeError`, with a mechanism to annotate which actually represent type errors (typically, those thrown by SpiderMonkey or `throw new TypeError`) and which do not (typically, most of the instances of `TypeError` thrown by DOM operations).
Differential Revision: https://phabricator.services.mozilla.com/D95276
Since bug 1652813, we have stopped counting shared memory as part of every single process. However, we haven't really counted it as part of any process. With this patch, we count shared memory as part of the parent process.
We also take this opportunity to harmonize the name of the (empty) CSS classes that we use to display memory, as they had distinct names on different rows for no reason.
Differential Revision: https://phabricator.services.mozilla.com/D95259
This patch makes use of the new "Baldrdash2020" ABI support in Cranelift
to support the "ABI 2020" refactor in the Wasm compiler.
Differential Revision: https://phabricator.services.mozilla.com/D93190
Depends on D83064
We remove Frame::tls and fix prologue/epilogue. Runtime, Ion and Baseline are ready for this move already.
Differential Revision: https://phabricator.services.mozilla.com/D83064
Depends on D83051
Here we remove remaining uses of Frame::tls. There are many places where
we use it: in debug frames, in profiling frames, in jit activation, etc.
All these places require short fixes to use our new scheme for getting
tls, so I gathered them together.
Differential Revision: https://phabricator.services.mozilla.com/D83051
Depends on D83045
Here we replace usage of Frame::tls in frame iteration with GetNearestEffectiveTls.
We also maintain current tls for frame iteration object to not to call GetNearestEffectiveTls everytime.
Differential Revision: https://phabricator.services.mozilla.com/D83045
Depends on D83044
This is the third part of series of patches to Frame without tls pointer.
Here we preserve initial tls in all entry stubs and then use it to find a proper tls instance for a given frame.
To find the TlsData* for specific frame we start from a entry stub's tls
and then track tls through all possible cross-instance calls. This logic
is implemented in GetNearestEffectiveTls procedure.
Then, we use this new procedure to make singal handling free from Frame::tls.
Differential Revision: https://phabricator.services.mozilla.com/D83044
Depends on D82888
This is a followup patch for removing Frame::tls.
Now, we are preserving caller's and callee's tls'es for all possible cross-instance calls in the previously allocated abi slots.
We also use preserved tls values to restore the caller's tls in Ion. Baseline doesn't need this because it restores the caller tls from its private stack slot after the call.
Differential Revision: https://phabricator.services.mozilla.com/D82888
Depends on D82881
We are going to remove Frame::tls and support trampolines for indirect calls, so we need to get rid of using Frame::tls.
In this and the followup patches I will iteratively remove all dependencies of Frame::tls and remove it eventually.
In this patch I changed wasm ABI to allocate two stack slots after stack args to preserve caller's and callee's tls'es in the near future.
Differential Revision: https://phabricator.services.mozilla.com/D82881
The test runs `execCommand("insertHorizontalRule")` when the document node
has no children. In this case, `TextFragmentData` fails to initialize itself.
In this case, our editor cannot do anything. Therefore, returning error
in this case must be better.
This patch makes all callers of the scan methods handle the error case unless
the caller cannot return error.
Comparing with Blink, perhaps, we should insert `<html>` and `<body>` element
in this case first and keep doing the requested operation in the future.
Currently, doing it may cause another complicated issue with mutation event
listeners.
Differential Revision: https://phabricator.services.mozilla.com/D95126
The reason of hitting the assertion is, a clipboard event listener nests
another edit action, initializing the editor, runs, and tries to create an
anonymous `<br>` element with transaction, but it checks whether `beforeinput`
event has already been dispatched or not with the parent edit action data.
For fixing it, this patch adds a flag to edit action data to indicate whether
a clipboard event has already been dispatched or not. If it's already been
dispatched, it's **okay** to modify the DOM tree. Ideally, we should put off
modifying the DOM tree after dispatching `beforeinput` event, but this case
does not notify web apps anything so that this patch should be fine.
Although this patch adds a crash test which is attached by the reporter,
it's not reproducible with current editor code because we stopped modifying
native anonymous nodes with transaction, but it depends on the behavior.
Still this assertion hits in `test_clipboard_noeditor.html` intermittently,
but I don't have idea how to reproduce this permanently. Therefore, this
patch does not contain a test to check to regression actually.
Differential Revision: https://phabricator.services.mozilla.com/D95115
It seems like the GeckoTextMarker::Range can sometimes return invalid ranges.
We need to check if they are valid or not before marshalling them.
Differential Revision: https://phabricator.services.mozilla.com/D95230
Actually, `DeleteNodeWithTransaction` cannot remove non-editable node. But
we should allow it which parent node is ediatble.
Differential Revision: https://phabricator.services.mozilla.com/D94937
Flex item's content size suggestion is the min-content size in the main
axis. Quoting from the CSS Sizing spec, section "5.1. Intrinsic Sizes",
The min-content size of a box in each axis is the size it would have
if it was a float given an auto size in that axis (and no minimum or
maximum size in that axis) and if its containing block was
zero-sized in that axis. (In other words, the minimum size it has
when sized as “shrink-to-fit”.)
However, all the frame types' GetMinISize() doesn't consider aspect
ratio (either the intrinsic aspect ratio on images or svg, or the
preferred aspect ratio set by the aspect-ratio property). That is, we
currently don't allow `aspect ratio * definite block-size` as part of
the equation in `inline-size:min-content` (bug 1646100 or bug 1670151).
Luckily, nsIFrame::ComputeSize() already takes care of this [2]. We just
need to add a flag to let ComputeSize() behave as if the flex item had
an auto inline size. The code should be similar to FloatMarginISize() in
BlockReflowInput.cpp except we are calculate the flex item's content-box
size.
[1] https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes
[2] https://searchfox.org/mozilla-central/rev/dbced93f1c57942501c23d4633d01ce59d9087a1/layout/generic/nsContainerFrame.cpp#2732,2735-2736
Differential Revision: https://phabricator.services.mozilla.com/D94802