This also adds a diagonstic assert to make sure the code works in all process types.
And it adds another item to the sandbox IOKit property name allowlist, so that
the detection works in content processes.
This landed before, in bug 1649490, but without the sandbox adjustment (so it
didn't work in content processes).
Differential Revision: https://phabricator.services.mozilla.com/D91950
I have no idea what the issue is, but this fixes it. I figure it's not
worth putting too much effort into since this was just to make the tests
as DRY as possible, and not actually important.
Differential Revision: https://phabricator.services.mozilla.com/D92237
The patch in bug 1666497 (which makes regular <window>-based XUL
documents with other the XHTML-based ones) uncovers an issue in the
anchored popup tests, which starts timing out.
The underlying issue is that it changes the reflow order from popups in
XUL-only documents with respect to their anchors. Note that Firefox
already uses the "broken" code, because we moved to xhtml and
browser.xhtml doesn't use a XUL <window> anymore.
Since we reflow now the popup _after_ the anchor rather than before, we
don't need to rely on CheckForAnchorChange() to deal with changes. This
means that we need to notify on the positioning changes that happen
during reflow though.
We should be able to simplify a bit the CheckForAnchorChange() stuff
now, but it also takes care of hiding popups and such so I don't plan to
do it on this bug to minimize risk.
Differential Revision: https://phabricator.services.mozilla.com/D91012
When we are looking at a transform of an element relative to the surface
it's rendered into, we used to only consider the final transformation
when determining back-face visibility.
However, in case there are any Flat reference frames on the way,
the transformation is flattened. We should be checking for back-face
visibility on each such step.
This doc was helpful, although it doesn't have all the answers:
https://docs.google.com/document/d/1yb4a_uhTG3KmcbGPta4B9p67v1HO_qY8ZMk-otGOwTc/
Differential Revision: https://phabricator.services.mozilla.com/D92135
Various cleanup:
- significantly simplify SIMD emitters in the baseline compiler: we
don't need to have various emitters with names like ...WithTemp and
...WithTwoTemps, it is enough to use the base name of the operation
and rely on overloading. This in turn leads to opportunities for
templates, which are introduced systematically here, leading to the
removal of many special-case emitters.
- remove some dead SIMD code in the masm
- rename a misnamed API (the SIMD averages are unsigned averages)
- rename some mismatched parameter names
Differential Revision: https://phabricator.services.mozilla.com/D90742
This lays the groundwork for ARM64 simd in the baseline compiler and
runtime. Mostly this is non-dramatic.
The main problem to be solved is SIMD register allocation and
save/restore in the stubs. We can't use the register sets in the
usual way to do this for reasons that are explained at length in
comments in Architecture-arm64.h, WasmStubs.cpp, and
WasmBaselineCompile.cpp, so there are a couple of cheats, that
basically come down to (sometimes contextually) treating doubles as
vectors. By and large this is surprisingly clean.
The patch also splits a huge test file (simd/spec/nan-flavors.js) into
many smaller files so as to avoid OOM conditions when testing on
device with --ion-eager and similar switch settings that cause massive
amounts of jit code to be allocated.
Differential Revision: https://phabricator.services.mozilla.com/D90740
Factor existing partial-OOB-store checks out of the SIMD tests into a
separate file.
Add non-SIMD partial-OOB-store tests in a separate file.
Disable these tests for ARM and ARM64 because we don't handle that
correctly on all devices yet.
Differential Revision: https://phabricator.services.mozilla.com/D91415
Automatic update from web-platform-tests
[css-flex] Pass a ConstraintSpace to ortho_table.ComputeMinMaxSizes()
ComputeMinMaxSizes needs a ConstraintSpace when the child is not in a
parallel writing mode. Flex wasn't providing one when it retrieved a
table's intrinsic min size.
Before this bug was introduced, flex was calling
ComputeMinAndMaxContentContribution(..., table, ...) instead of
table.ComputeMinMaxSizes(...). ComputeMinAndMaxContentContribution
builds its own ConstraintSpace for ortho items, so flex didn't need to
provide one.
We originally switched from ComputeMinAndMaxContentContribution to
table.ComputeMinMaxSizes because:
* One input to the flex algorithm is the item's used min-width (for a
row flexbox). The flex algorithm will never assign a flex item a width
smaller than its used min-width. For most elements, we get this value
via ResolveMinInlineLength(..., style.LogicalMinWidth(), ...).
* But table's used min-width is defined specially to be "the greater of
the resolved min-width, CAPMIN, and GRIDMIN". So to get the
table-as-flex-item's used min-width, we need to retrieve max(CAPMIN,
GRIDMIN) in addition to resolving style.LogicalMinWidth from the
above step.
* ComputeMinAndMaxContentContribution(table).min returns max(CAPMIN,
GRIDMIN, style.LogicalWidth()). I.e. it obeys any specified width on
the table.
* But table.ComputeMinMaxSizes().min returns only max(CAPMIN, GRIDMIN)[1],
which is what we want.
In the example below, the flexbox will try to shrink the table's width
to 75px. Using ComputeMinAndMaxContentContribution for the table's
min-width computation would result in the table being 100px wide. Using
table.ComputeMinMaxSizes would make it 75px wide. 75px is correct.
<div style="display: flex; width: 75px;">
<table style="width: 100px; min-width: 0px;">
<td>
<div style="float: left; width:50px"></div>
<div style="float: left; width:50px"></div>
</td>
</table>
</div>
https://jsfiddle.net/dgrogan/gwu4ac82/3/
[1] This is actually not true today but is true for TablesNG. Switching
to table.ComputeMinMaxSizes gets us closer.
Bug: 1128262
Fixed: 1131890
Change-Id: Ie5a4eac97e4a6a2e96104397bd5c5ec483d40e78
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2433594
Commit-Queue: David Grogan <dgrogan@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#811216}
--
wpt-commits: 2531feaeef0530450b7a7271b2bb4cc450edb831
wpt-pr: 25805
Automatic update from web-platform-tests
Increase timeout of Content-Security-Policy WP test
The WP test
content-security-policy/embedded-enforcement/required_csp-header-crlf.html
has been marked as flaky lately on Mac because it was incurring in the
timeout (see https://crbug.com/1091896). Since the test opens and
navigates several iframes, this is understandable, so let's increase
the timeout.
Bug: 1091896
Change-Id: Ibdc05589eed0188a4782f45693963aa15cfb671a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2435347
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#811199}
--
wpt-commits: df557c6e8643150676ce4d4a3c5145dbd0c1ecf0
wpt-pr: 25811
Automatic update from web-platform-tests
Reset trailing space structure when rewinding due to overflow handling
During the HandleOverflow we consider the possibility of breaking at
previous opportunity. The logic for this case is implemented in the
BreakTextAtPreviousBreakOpportunity function.
In case that there is such suitable previous opportunity, we modify the
ItemResult that includes this opportunity in its offset range. We also
create a new ShapeResultView associated to this item_result, using the
new offset range.
However, it's possible that the trailing_collapsible_space_ structure
already has this ItemResult instance, that we are now altering as part
of the HandleOverflow logic.
The problem described in the issue 1131470 is caused by this situation,
where an ItemResult instance hold by the trailing_collapsible_space_ is
modified. During the computation of the trailing spaces size, as part
of the RemoveTrailingCollapsibleSpace function, we avoid calling to the
TruncateLineEndResult, which will reshape again, in case the item_result
considered is already present in the trailing_collapsible_space_
structure. This causes that we end up with an ItemREsult of a different
size than the previously computed collapsed_shape_result.
Bug: 1131470
Change-Id: I15b31303fb8ec52b6d7359880f2785d16e1a0c59
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2429411
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#811115}
--
wpt-commits: 1916d3f4f67ab06325b4f0f8ac65b5ebad404bf2
wpt-pr: 25795
Automatic update from web-platform-tests
The adjusted_start must be computed based on the part_start
In order to create a new ShapeResultView, we use segments of a previous
instance, analyzing its runs based on a new index range for the new
instance. Since the start/end of the RunInfo structure may be different
than the start index of the ShapeResultView, we use an adjusted_start
to adapt the logic to the different data structures.
We assume that if the passed start_index for the new range is greater
than the current run's part start being processed, we should define the
new run's start as the difference of these two values. However, we must
also ensure that start_index is at least equal to the the part_start
value for such run.
The problem described in the issue 1130153 comes from the fact that
we use the start_index on cases where it's smaller than the run's
part_start. This leads to an incorrect (longer than expected) run.
Bug: 1130153
Change-Id: Id5dd505baf1f990d2fe7a9406e191979cbd6b9f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2431523
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#811105}
--
wpt-commits: f2cb066328f2035c20b2a9726febd82056b7ac41
wpt-pr: 25804
Automatic update from web-platform-tests
Invalidate GraphicsLayer::CcLayer() when switching "create layers after paint"
When we switch on "create layers after paint" and back, the contents of
the original GraphicsLayer::CcLayer() and RasterInvalidator which are
not used during "create layers after paint" may not be valid.
Invalidate them to ensure correct rendering.
Bug: 1132218
Change-Id: Ia717e8202e2627cedbc9e5305619223a5a833f47
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2432766
Reviewed-by: Philip Rogers <pdr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#811013}
--
wpt-commits: 589d1d54b73d37f1efde64f75cc408bdd640b44a
wpt-pr: 25796
Automatic update from web-platform-tests
Add testing of :defined prior to call to super()
Per the conversation here [1], there is a desire to add more
testing of the :defined pseudo state, prior to the call to super().
Note that `this` is not accessible prior to super(), so the
instance itself is used. Also note that :defined already does not
match anywhere inside the constructor, for upgrades.
[1] https://github.com/whatwg/dom/pull/894#discussion_r495092027
Bug: 1042130
Change-Id: I2372900981247ea5624e737d2597d004398de477
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2431558
Auto-Submit: Mason Freed <masonfreed@chromium.org>
Commit-Queue: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/master@{#810991}
--
wpt-commits: 0e252e7d3d8f95725f6ae177148da85eac333ca2
wpt-pr: 25794
The math-depth implementation is refined to take into account the
ScriptPercentScaleDown and ScriptScriptPercentScaleDown constants (if the
parent's first valid font has a MATH table) in order to calculate the
scale factor between math-deth 0 and 1, and between 0 and 2 respectively.
Behavior is unchanged if the legacy scriptsizemultiplier attribute is
specified or if no MATH table is available.
The preference layout.css.math-depth.enabled remains disabled in nightly
until the remaining bit (support for font-size: math) is implemented in
bug 1667090.
Differential Revision: https://phabricator.services.mozilla.com/D91604
Until bug 1617002 Firefox would unintendedly not get unredirected on X11
when used with WR and OpenGL as it didn't fullfill the requirements -
not being transparent.
Now that this is fixed, fullscreen unredirection can happen on certain
compositors. For the basic compositor we already explicitely ask to not
get unredirected - do that for all backends.
Differential Revision: https://phabricator.services.mozilla.com/D92180
The build script was broken because of the usage of the optional chaining operator,
which is not supported by Node yet, so we fix it.
We also move one modification that was made for Bug 1651443 directly to
codemirror.css (which should be an exact copy of what's provided by the library),
to mozilla.css, our internal, devtools-specific stylesheet.
Differential Revision: https://phabricator.services.mozilla.com/D92041
