This adds a shell function 'clearModules' to clear all loaded modules, so that
tests can be insulated from one another.
Depends on D151834
Differential Revision: https://phabricator.services.mozilla.com/D151835
As per the lastest spec this now stays true after evaluation.
This patch keeps a very similar implemenatation and resets the field after
evaluation, except that we now report this special value as true rather than
false. We assert if we try and use get the sort order after this has happened.
We also reset the runtime counter in the same way as before.
Differential Revision: https://phabricator.services.mozilla.com/D151833
This lets us replace relatively slow TLS lookups with a simple dereference.
This also removes the realm from `JitContext`. The runtime still has a few uses
in the MIR backend.
Depends on D152849
Differential Revision: https://phabricator.services.mozilla.com/D152850
`MacroAssembler` now has a single constructor, instead of three different ones
before this patch stack.
Depends on D152847
Differential Revision: https://phabricator.services.mozilla.com/D152848
This follows the Wasm code and prepares for (a) removing the second `MacroAssembler`
constructor and (b) removing the allocator from `JitContext`.
Depends on D152846
Differential Revision: https://phabricator.services.mozilla.com/D152847
This removes some old code to tag debug spew with an ID per assembler, based on a
counter stored in `JitContext`. Usually there's only one assembler per `JitContext` and
we were also not using this for Wasm compilations (it always used id 0), so this
patch removes it.
Depends on D152766
Differential Revision: https://phabricator.services.mozilla.com/D152846
With this patch we always pass a non-null allocator to the `JitContext` constructor,
and then never change it. Use references instead of pointers to make this clearer.
This lets us clean up more code: `AutoJitContextAlloc` can be removed and the
`MacroAssembler` no longer needs the constructor to optionally instantiate that
class.
Differential Revision: https://phabricator.services.mozilla.com/D152765
One of the `MacroAssembler` constructors instantiates a `JitContext` lazily, but
it's simpler to require the callers to create a `JitContext`.
Differential Revision: https://phabricator.services.mozilla.com/D152763
A long time ago, `JitContext` was also used for entering JIT code, but now we only
use it for the compiler backend where we don't need to support nesting.
This requires some minor changes to avoid having multiple active contexts on the
stack, but makes it easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D152762
We can skip checks for `input.value != input.defaultValue` by using `lastInteractiveValue` which tells us what user typed in the field.
Differential Revision: https://phabricator.services.mozilla.com/D150990
We store active duration as int64_t, multiplying a finite duration by a finite
iteration count would result over INT64_MAX, it will be represented as a
negative integer value. Both animation duration and interation count should
never be negative, thus multiplying them also should be positive so that
treating such kind of overflowed values as infinite would be more reasonable
than treating it as negative.
Differential Revision: https://phabricator.services.mozilla.com/D152721
Currently, `HTMLEditor` assumes that padding `<br>` element for empty last line
is outside of inline elements, but it may happen because of both:
* starting from bug 1778091, `HTMLEditor` move `<br>` element into new empty
inline elements at inserting new paragraph.
* web apps can put it into inline elements.
After splitting inline elements and which do not have meaningful content, users
cannot put caret into the empty inline elements so that the elements stay unless
delete around there.
For avoiding the leak due to meaningless elements, we should delete them at
splitting inline elements at inserting new text.
Note that Chrome does not pass the new tests of resetting ancestor bold style
because Chrome wraps the `<b>` with `<i>`, however, the `<i>` has odd
`style=""`. Perhaps, the test framework should ignore it because it's not
important for the web-compatibility.
On the other hand, Chrome completely fails only the last testcase since it
unwraps the `<b>` from the last `<br>`, so the bold style which was applied by
the web app to the last `<br>` is lost. This is not reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D152616
The baldrdash integration of Cranelift is agreed between SM and CL
to be the wrong shape. Our import of the code base is also old and
causes difficulties for us when upgrading some crates (see bug
1774829). We should remove it for now to unblock bug 1774829.
Differential Revision: https://phabricator.services.mozilla.com/D152806
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
In nsReflowStatus::UpdateTruncated(), mTruncated can be true only when
mIsTopOfPage is false. However, when we reflow -moz-column-content, we always
set mIsTopOfPage to true. Therefore, IsTruncated() always returns false, i.e.
`!IsTruncated()` is always true.
Differential Revision: https://phabricator.services.mozilla.com/D151460
We call NS_FRAME_SET_TRUNCATION (via nsReflowStatus::UpdateTruncated) in the end
of every frame's Reflow() to update nsReflowStatus::mTruncated bit. In the
following patches, I'm going to rewrite all the callers of IsTruncated(), and
ultimately remove the mTruncated bit.
In this patch, I rewrite the callsite in ReflowCellFrame() by moving
nsReflowStatus::UpdateTruncated logic [1] into it. Note that we use an assertion
in ReflowCellFrame to make sure nsTableRowFrame and nsTableCellFrame have the
same writing-mode.
The only test covering the code path is `layout/reftests/bugs/409084-1a.html`.
[1] https://searchfox.org/mozilla-central/rev/2946e9b450cb35afaf8dad927a8d187975dcd74d/layout/generic/nsIFrame.cpp#256-258
Differential Revision: https://phabricator.services.mozilla.com/D151459
This patch adds a new Content Blocking Eveent flag and modifies the
current email tracking event flag. This would allow us to log the
loading of email tracker in two levels. The level 1 email tracker
contains the base list of the email trackers, The level 2 email tracker
contains both base and content email trackers.
Differential Revision: https://phabricator.services.mozilla.com/D152679