The non-native theme does two things which, combined, cause this test to
fail.
The first one is that it has slightly bigger checkboxes than other
themes (14px vs. 13px).
The second one is that it has a 2px widget-imposed border, like Mac:
https://searchfox.org/mozilla-central/rev/0dfbe5a699cc6c73cf8c14d1aa10ba10ef3ec8fa/widget/nsNativeBasicTheme.cpp#1367-1369
Which causes its baseline to go down by that amount. This was done
intentionally in bug 1675389, though I guess it could be reconsidered.
These two things combined make the checkbox grow the line slightly in
this test-case, causing the elements to move 1px apart.
The test is intended to check that the baseline calculation of a
checkbox/radio is correct, which it is, so prevent that undesired side
effect by resetting the margin to zero.
Differential Revision: https://phabricator.services.mozilla.com/D103324
Without this the non-native theme fails the last assertion of the test.
I couldn't reproduce locally but the word that it's supposed to be
selected is very close to being out of the iframe viewport on my
machine, so it'd make sense if the new non-native theme, which has a bit
more padding, causes the word to move a bit further down.
I've confirmed this fixes the issue.
Differential Revision: https://phabricator.services.mozilla.com/D103317
Instead of accessing Scope from AbstractScopePtr, pre-calculate necessary
information in ScopeContext.
Also removed GCThingList.stencil field that's now unnecessary.
Depends on D103453
Differential Revision: https://phabricator.services.mozilla.com/D103454
Remove the flipping of the data pref during FOG init test because, with the
dispatcher now a part of the RLB, this isn't something we should test at this
level.
Differential Revision: https://phabricator.services.mozilla.com/D103379
Automate some of the copy event tests which tested for this, since there
seems we/WPT don't have a lot of coverage for them.
Differential Revision: https://phabricator.services.mozilla.com/D103428
Generalize the SIMD wormhole to both x86 and x64, and both baseline
and Ion, so that we can start experimenting with it on a broader
scale.
Change the config so that the feature will ride the trains,
preffed-off bydefault (the current setting).
Differential Revision: https://phabricator.services.mozilla.com/D101709
nsBaseHashtable now supports non-default-constructible DataType and
UserDataType, however not all methods can be instantiated. All methods which
can't be instantiated with non-default-constructible DataType or UserDataType
are now described as such in method definitions.
The public API of PLDHashTable and nsBaseHashtable/nsDataHashtable was changed:
- A new method PLDHashTable::WithEntryHandle has been added. It allows to use a
custom function for entry initialization (instead of the global hook).
- A new method nsBaseHashtable::MaybeGet has been added.
- A new overload nsBaseHashtable::Remove has been added.
- The nsDataHashtable::GetAndRemove method has been pulled up to
nsBaseHashtable.
In addition, the following implementation details have changed:
PLDHashTable:
- The code from the Add method has been split into MakeEntryHandle and a helper
object called EntryHandle. The Add method is now implemented on top of that.
nsTHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- The InitEntry hook is no longer used. Instead of using the hook, PutEntry
methods now use nsTHashtable::WithEntryHandle instead of PLDHashTable::Add.
This change allows to do custom initialization in derived classes.
nsBaseHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- Put methods no longer use nsTHashtable::PutEntry, they now use the new method
nsBaseHashtable::WithEntryHandle.
Differential Revision: https://phabricator.services.mozilla.com/D99428
Some client bindings will send over the headers with either a capital
first letter and some might not. We need to handle all cases
Differential Revision: https://phabricator.services.mozilla.com/D103384
This switches all CacheIR and MIR instructions that use a TypedArray or DataView
index from Int32 to IntPtr.
The int32-index and non-int32-index cases in the GetElem/SetElem/In CacheIR generators
are now unified into a single method. This way it's easy to see that in-bounds Int32
and Double indexes are handled exactly the same way.
The IRGenerators call IRGenerator::guardToIntPtrIndex to convert key values to an
IntPtrOperandId. All TypedArray/DataView accesses optimized by CacheIR go through
there now.
The GuardToTypedArrayIndex CacheIR and MIR instruction is replaced with a similar
GuardNumberToIntPtrIndex instruction. It accepts a Number instead of a Value.
Differential Revision: https://phabricator.services.mozilla.com/D102739
Adds useRegisterOrIndexConstant to check this during lowering, and also uses
ArrayOffsetFitsInInt32 in codegen to assert no overflow.
Differential Revision: https://phabricator.services.mozilla.com/D103154