Automatic update from web-platform-tests
[PaymentHandler] Avoid crash from too-long icon type
Before this CL, passing a (very) large string for an icon's type to
paymentManager.instruments.set would result in mojo killing the
renderer for being badly behaved. This CL changes the Blink-side logic
to truncate the type to 4096 characters, which should be more than
enough given the type has to be a valid MIME type by spec[0].
[0]: https://www.w3.org/TR/payment-handler/#dfn-convert-image-objects
Bug: 810792
Change-Id: I78beebb9d934d321c640b8238ad27d094fd6b3dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3283985
Reviewed-by: Rouslan Solomakhin <rouslan@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#942156}
--
wpt-commits: eb0e4d11a3445af73a8281d0bd1a339a5bdb7516
wpt-pr: 31646
Automatic update from web-platform-tests
fix(conformance-checkers): U+007C (|) is now a forbidden host code per url standard (validator issue 1207)
--
wpt-commits: 312afcfe4f54add602d1200ab613c3e894b2688c
wpt-pr: 31354
Automatic update from web-platform-tests
[Azure Pipelines] Upgrade to macOS 11 (Big Sur) (#30256)
This moves to using acceptInsecureCerts with a new enough release of
Safari, which removes the blocker to running STP on Azure Pipelines
documented in #31147, whereby trusting certificates in Big Sur or
later requires either user interaction or SIP being disabled, which is
infeasible on Azure Pipelines. See
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes#Security
for details about the behaviour change in Big Sur.
For now, this keeps Safari (stable) on Catalina, as it doesn't support
acceptInsecureCerts.
Additionally, this moves all usage of Python on Big Sur to 3.7, as 3.6
is not available Azure Pipelines' macOS 11 VMs.
--
wpt-commits: 5c2d714ee3a56d680604591e61a36d80513451a6
wpt-pr: 30256
Automatic update from web-platform-tests
Remove crash expectation for rtp-payloadtypes on Linux
Also log failing payload type in test.
Note: the bug blamed in TestExpectations (1200671) seems irrelevant.
Bug: none
Change-Id: Id017ef6354467534598978f259b2d72a8466f46b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3284643
Reviewed-by: Florent Castelli <orphis@chromium.org>
Commit-Queue: Harald Alvestrand <hta@chromium.org>
Cr-Commit-Position: refs/heads/main@{#942099}
--
wpt-commits: b2269ffb31dca6b03da48a1a9c5ef4fa7b01a1b8
wpt-pr: 31644
Automatic update from web-platform-tests
Refactor out common partitioned service worker WPT code
Refactor common utility functions into their own file to reduce
duplicate code.
Bug: 1246549
Change-Id: Ib14ae0359f63f00848ea5d6b2ee8b723d4e7e30a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3279125
Reviewed-by: Ben Kelly <wanderview@chromium.org>
Commit-Queue: Steven Bingler <bingler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941711}
--
wpt-commits: fe4e89cfbaa984f46765e00d962389f410290656
wpt-pr: 31621
Automatic update from web-platform-tests
[GridFragmentation] Support break-inside:avoid with MovePastBreakpoint
This patch adds support for avoiding un-appealing breaks inside items
by using MovePastBreakpoint.
If the current row for an item has container-separation, and
MovePastBreakpoint returns false - we should move the entire row into
the next fragmentainer.
This implicitly expands the intrinsic block-size of the grid.
The grid-data structures currently assume that we can't have "holes" in
our grid needed to support this. (Or at least non-uniform "holes"
grid-gap/align-items/etc are all currently uniform).
To support the grid splitting in this way it also introduces
row_offset_adjustments to accommodate pushing a particular row into the
next fragmentainer.
Bug: 614667
Change-Id: I252fecc122ade410eb9b574836d64de3d82eb72d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3270413
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#941957}
--
wpt-commits: c0ada9a809dead12f56cf52069a60c269b2cea7e
wpt-pr: 31625
Automatic update from web-platform-tests
Do not skip compositing update for non-animation transform changes
Properties like "will-change: transform" are direct compositing reasons
which let us skip raster when properties change. Usually, we still need
to update compositing when directly-composited transforms change because
overlap can change. An exception to this is animations which assume
worst-case overlap in |PendingLayer::VisualRectForOverlapTesting|. This
patch stops skipping the compositing update for non-animation transform
changes.
An alternative approach of assuming worst-case overlap for will-change
transform was investigated in https://crrev.com/c/3280439 but this has
two downsides: complexity and compositing memory (a good example is
composited-scroll-overlap-test.html). Before CompositeAfterPaint, we
would need to run compositing as well, so the approach in this patch
has precedent. We may want to expand the visual rect for
will-change: transform in the future, for performance parity with
animations.
Bug: 1267689
Change-Id: I9812426e9a159bdbe44476390e10fe53478f9ccc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3282945
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941904}
--
wpt-commits: 22bf1f9e0ed1f729fb91632c39b2c8d68844f503
wpt-pr: 31635
Automatic update from web-platform-tests
[css-backgrounds] Add test for background-clip on multi-line inline elements (#30812)
Co-authored-by: Tim Nguyen <nt1m@users.noreply.github.com>
--
wpt-commits: 1cdd682a491f3301445ee0dadc312bf53b2ae851
wpt-pr: 30812
Automatic update from web-platform-tests
[SelectMenu] Expose validity related APIs.
This CL exposes validity related properties: willValidate, validity,
validationMessage, checkValidity, reportValidity, setCustomValidity.
For now, the value missing algorithm matches the one used for
<select>[1].
ListedElement that is extended by HTMLSelectMenuElement already provides
many of the needed functionalities.
Added selectmenu-validity.tentative.html to validate the change.
[1]: https://html.spec.whatwg.org/multipage/form-elements.html#attr-select-required
Bug: 1121840
Change-Id: Id88188ac89992f0c0ae5a5ae293c5714cd2a8e50
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3277534
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: Ionel Popescu <iopopesc@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#941834}
--
wpt-commits: 91d541b2e3fac8096d2100876454491dd2104d8f
wpt-pr: 31612
Automatic update from web-platform-tests
[SelectMenu] Remove not needed behavior='option' from tests.
After[1], only <option> elements are supported as <selectmenu> option
parts so there is no need to have behavior='option' in tests, other
than ensuring that controller code is not applied.
[1]: http://crrev.com/c/3251854
Bug: 1121840
Change-Id: Ibe7ac978847f4e4e5e3de13eb742d448ece9d21a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3279568
Auto-Submit: Ionel Popescu <iopopesc@microsoft.com>
Commit-Queue: Mason Freed <masonf@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941815}
--
wpt-commits: 61f6a6e194b11e448889ec23af9bc37a1eda1b60
wpt-pr: 31620
Automatic update from web-platform-tests
Add WPT for Partitioned Service Worker matchAll
Adds a WPT that tests that clients.matchAll is properly
partitioned when storage partitioning is enabled.
(For chrome) Also runs the test as part of the third-party storage
partitioning virtual test suite.
Also cleans up some commented out code.
Bug: 1246549
Change-Id: If0479dc00e90657bfd7eb902c5605a2e54afc42d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3279500
Commit-Queue: Steven Bingler <bingler@chromium.org>
Reviewed-by: Ben Kelly <wanderview@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941752}
--
wpt-commits: e1d84ebfaf15eadbae21ab1c2512152b61967be5
wpt-pr: 31619
Automatic update from web-platform-tests
Add ShadowRoot check in single node forced unlock
Starting a FlatTreeTraversal with a ShadowRoot DCHECKs, so this patch
uses the ShadowRoot's host in that case, which is basically the same
node in the flat tree.
Fixed: 1269743
Change-Id: I8810d462eec06c6a185cc875057738e065f79cf3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3279873
Reviewed-by: vmpstr <vmpstr@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941696}
--
wpt-commits: f6c2e6f71fd75548d56983fd2c9563605c6c76c1
wpt-pr: 31626
Automatic update from web-platform-tests
[SPC] Add testdriver support for the SPC set-mode command
--
[SPC] Add auth-time tests using the new webdriver hooks
--
wpt-commits: ae483100a12ee8e7110c95142f95b14f2d659f6a, ca7ae270b01710cc3f4201d03bdf837321649a1a
wpt-pr: 31345
Oddly, `nsContentUtils` does not register touch events in desktop environments
which do have a touch screen into the map of `EventMessage` and `nsGkAtoms`.
However, `AddEventListenerInternal()` needs to cache whether there are some
touch event listeners since touch screen may be connected later. Therefore,
this patch makes `AddEventListenerInternal()` adjusts `aEventMessage` only
when given event message is `eUnidentifiedEvent` and given `nsAtom` is one
of the touch events before the `switch` statement. I guess that the dynamical
registration is for some handlers of touch events, but from the point of view
of `EventListenerManager`, there should be another way to check whether touch
events may be fired or not, and the mapping table should be same in any
environments. However, it's out of scope of this cleaning up bug and
fortunately, we can skip the additional check with the `eUnidentifiedEvent`
check and `nsAtom::IsStatic()` check.
Differential Revision: https://phabricator.services.mozilla.com/D131760
Current code firstly check whether the given event message is a pointer event
message or not, but it does not necessary for `switch` statement. Thus, we
can make it simpler with the `switch` statement.
Differential Revision: https://phabricator.services.mozilla.com/D131757
In theory, `switch` statement is faster than `if` - `else if`s especially when
there are a lot of `else if`s. Although it may be optimized by the compilers
in these days, but they may have same performance even in the worst case.
So if we can rewrite the big `if` - `else if` block in
`EventListenerManager::AddEventListenerInternal()` with a `switch` statement,
it may become faster and anyway looks much simpler.
A lot of them compares an `nsAtom` pointer and `nsGkAtoms`, and the others
compares `EventMessage`. Fortunately, it treats only known events which
are registered both in `EventMessage` and `nsGkAtoms`. Therefore, we can
use `switch` statement with `EventMessage`.
For detecting unexpected regressions, this and the following patches put
`NS_ASSERTION`s into the `default` block. Unfortunately, we cannot output
dynamic values like the value of variables with `MOZ_ASSERT`, we need to
use `NS_ASSERTION` here. See bug 779173.
Differential Revision: https://phabricator.services.mozilla.com/D131756
Bug 1713092 adds a few MIR folding rules, including ones to remove xor32 with
all-ones inputs. That unfortunately does not generalise to the 64-bit case
because MBitNot is hardwired to Int32, so there's no way to represent the
result. This patch enables MBitNot to also take Int64, enables the relevant
folding rules, and adds LIR-level support for that on {x86,arm}{32,64}.
jit-test/tests/wasm/binop-x64-ion-folding.js, jit-test/tests/wasm/integer.js
* New test cases.
jit/MIR.h, jit/RangeAnalysis.cpp
* allow MBitNot to also handle Int64
jit/MIR.cpp
* MWasmBinaryBitwise::foldsTo: enable folding xor64 with an all-ones input
jit/LIROps.yaml, jit/Lowering.cpp
* new LIR node BitNotI64, and lowering to it.
jit/arm/Lowering-arm.h, jit/arm/Lowering-arm.cpp, jit/arm/CodeGenerator-arm.cpp
and equivalents for arm64, x64, x32
* new overload for lowerForALUInt64()
* new function CodeGenerator::visitBitNotI64()
Differential Revision: https://phabricator.services.mozilla.com/D131887
The challenges here are:
* xpcshell tests still don't support the watcher actor and server side targets. So we have to ensure still using client side target fetched via Descriptor.getTarget RDP request. (We still also need that for WebExtension)
* some tests weren't spawning the TargetCommand while querying TabDescriptor.getTarget. I tuned them to call TargetCommand.startListening so that we start instantiating server side targets, including the top level one retrieved via TabDescriptor.getTarget.
Otherwise, thanks to this patch a few check can now be moved from `if (isLocalTab)` to `if (isTabDescriptor)`.
Differential Revision: https://phabricator.services.mozilla.com/D130761
We ended up having duplicated JSWindowActorTransport's when detaching the target.
This only reproduces in case of remote debugging, where we detach/destroy the top target
when closing the toolbox. And we later reuse the same DevToolsClient to spawn a new
WindowGlobalTargetActor, with a new Transport.
But as the old transport was still around, we ended up duplicating the packets.
In this patch, I'm also tuning WindowGlobalTargetActor.destroy to avoid crashing
if the target wasn't attached when we destroy it, and avoid trying to destroy
twice if destroy is reentrant.
Differential Revision: https://phabricator.services.mozilla.com/D131914
This wasn't used except for a test and wasn't working with server side targets.
Making this compatible with SST wasn't trivial, so I went for removing this.
Differential Revision: https://phabricator.services.mozilla.com/D130919
This patch is meant to be a proposed short run fix to prevent ApplyAddonContentScriptCSP
from leaking the ExpandedPrincipal and nsCSPContext instance because they keep a reference
to each other.
This patch prevent that leak by creating a clone of the ExpandedPrincipal and then use
that cloned instance in the call to nsCSPContext::SetRequestContextWithPrincipal.
Once Bug 1548468 will move the CSP off the ExpandedPrincipal class, cloning the expanded
principal to prevent that leak should not be necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D132144
dependabot[bot]
Stephen McGruer
Mark Rogers
Philip Jägenstedt
Harald Alvestrand
Vladimir Levin
Steven Bingler
moz-wptsync-bot
Ian Kilpatrick
Philip Rogers
Myles C. Maxfield
Fernando Fiori
Ionel Popescu
Joey Arhar
Masayuki Nakano
Nika Layzell
Henrik Skupin
Julian Seward
Olli Pettay
Ben Hearsum
Butkovits Atila
Andreea Pavel
Alexandre Poirot
Micah Tigley
Tooru Fujisawa
Luca Greco