Automatic update from web-platform-tests
Remove testdriver.js from a test that doesn't use it (#43938)
This is a reftest, and test_driver isn't used.
--
wpt-commits: c58ece1f015ba7b9a4d212a928e755bfdef7523f
wpt-pr: 43938
Automatic update from web-platform-tests
Support logical direction relative units in highlights
Add tracking in the style system for the use of logical
direction relative units (e.g. vi, vb, cqi, cqb etc).
Make use of the tracking to detect a change in logical
direction necessitating highlight style recalc.
Add WPT tests.
Bug: 1468306
Change-Id: I730f183b171d504df131430f69475ad56bb46ebb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5172505
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1246056}
--
wpt-commits: ae27ac9c8b718cd2abbc632f34c525d5068fbecf
wpt-pr: 43861
Automatic update from web-platform-tests
Increase max frame count in observeScrolling helper.
When threaded compositing is disabled, frames are not tied to vsync and
may pump more quickly (at intervals as short as 1ms, see task posted in
WebTestWebFrameWidgetImpl::ScheduleAnimationInternal).
This means the test may observe more than 500 frames before the end of a
smooth scroll, when running under run_web_tests.py on Chromium bots.
Bug: 888443
Change-Id: I6b2d45cbb1ee7c346e07bc5b5ad0c6d295fd127a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5184797
Commit-Queue: Steve Kobes <skobes@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1246027}
--
wpt-commits: 7c8dd639af571cf87d7720d92ec8789b03069963
wpt-pr: 43927
Automatic update from web-platform-tests
Fix Highlight Pseudos using container-relative units
Add support for creating a new style when the highlight uses
container-relative units and has a different container to that
of its parent. And also fix a problem where highlight styles
are not created inside container queries for the container itself.
Add testing of highlights using container queries.
Fixes a typo too.
Units depending on block/inline direction still do
not work for vertical writing modes. That's for another CL.
Bug: 1468306
Change-Id: I781a35810133f3591c7a3587ff5d13df0dfac9ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5149171
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1245980}
--
wpt-commits: 217ab9f1480ea3ebce180e7cf9f787246691bfe7
wpt-pr: 43848
Automatic update from web-platform-tests
Allow non-opaque fenced frames to inherit select permissions.
For fenced frames with unpartitioned data access, they will need to use
Shared Storage in order to read and write the unpartitioned data. They
will also need to be able to call the Private Aggregation API in order
to send reports and telemetry without running the risk of introducing a
fingerprinting vector. Both of those features are permissions
policy-backed features.
Fenced frames do not currently support permissions policies, so none of
these features will be able to be enabled. The reason we disabled
permissions policies originally was to prevent cross-channel
communication from the embedder into the fenced frame. However, fenced
frames with unpartitioned data do allow for data inflow, just not data
outflow. Because of that, we can now allow permissions policies to be
enabled on non-opaque fenced frames (i.e. fenced frames not created
using Protected Audience or Shared Storage).
This CL allows fenced frames to set and inherit permissions policies.
Only Shared Storage and Private Aggregation can be turned on. All other
permissions policies will be forced off if attempted to be enabled or
inherited, and a console warning will be output for debugging purposes.
Note that fenced frames created through Protected Audience or Shared
Storage will continue to have their existing restrictions, and this CL
will not affect their behavior.
As a feature of its architecture, MPArch does not have access to
permissions policy information in its parent on the renderer side. To
give a fenced frame that access, we need to explicitly give it that
information through the fenced frame properties. This CL adds the parent
frame's parsed permissions policies and its origin to the
FencedFrameConfig and FencedFrameProperties objects. This is done
instead of just adding the PermissionsPolicy object for IPC reasons. The
parsed permissions policies and origin can be sent in an IPC message and
are the 2 pieces needed in order to reconstruct a PermissionsPolicy on
the renderer-side.
This CL also fixes an issue where container policies for fenced frame
roots were not taken into consideration when building the permissions
policy on the renderer side.
This CL explicitly does not modify any permissions policy code related
to client hints. That will be done as a follow up if and when we choose
to allow client hints in fenced frames.
Change-Id: I00e56dc35e07e7dfa16a3b57eb40be384faa8252
Bug: 1515327
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5150117
Commit-Queue: Liam Brady <lbrady@google.com>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1245934}
--
wpt-commits: 53f423e0cb532d1cd6f38cbeacbf5f3205397d10
wpt-pr: 43846
Automatic update from web-platform-tests
[wptrunner] Do not index `wpttest.Test`, which is not subscriptable (#43932)
--
wpt-commits: 3a92f8181b1b336fe88a223e6183542457ba0749
wpt-pr: 43932
The DirectWrite "bold simulation" has poor results with some fonts;
we already disable it by default for webfonts, to avoid rendering
issues.
As it also works poorly with some of the component layers in Segoe UI
Emoji, let's disable it for COLR fonts as well.
Differential Revision: https://phabricator.services.mozilla.com/D198495
We shouldn't show the popup for keywords (`const`, `let`, `for`, …).
codeMirror marks those with the `cm-keyword` class, so we can ignore those in `_isInvalidTarget`,
but we need to exclude `this`, for which we do want to show the preview.
Differential Revision: https://phabricator.services.mozilla.com/D197585
be -> 40ae0b2f2409e289cdb8e0b11e38b84b4702fb93
da -> 3b8d008d8d271dfbf76f84c191f83a7f2f00fcb6
de -> cc95c50ca136ab46cb995c9ec24bb37a55f2c77f
eo -> 881cda8106ff2905596269ce90f4bcad365128db
fi -> 6b6d25e6bbce933f7e5c1c48f82050609c2069f8
ia -> 159d0da004c623b664442f8dc30dcde386479bad
oc -> 2e92a8e99efe6a3c929912951ed554c7d60f61a9
pl -> c1f55ff191e1574e7cfe4f729c6bbf28db36a4b0
sk -> 3fb3cdbaa071163ecca888c93d4e871ce4bcb3f5
skr -> 38f23c542ee88599a02cc2d81dfca0f408fc3a91
tg -> a9b91f0a75b15bba755543802e1b087fe51a31fb
uk -> 45f6e3cdd2db5eb74d8c98e3bf74b2e664fb1f6f
vi -> ae23581802923b481694864d954511884dbda33f
Canvas2D currently requires GetRemoteTexture to wait for an available texture owner. However,
WebGL and WebGPU should not actually wait in GetRemoteTexture because they implement the wait
elsewhere on the client-side, nor do they actually implement forwarder transaction id logging
so it is not safe to use the timed wait for them here.
This takes the path of least resistance by plumbing a flag in TextureFlags to pass this information
along.
Differential Revision: https://phabricator.services.mozilla.com/D198499
The method does not assume that an inline ancestor is not a splittable, but
it may occur in the edge cases.
I tried to make `HTMLEditor` adjust selection range at starting deletion to
stop handling it or select the most distant unmodifiable element, but it
requires some expectation changes of tentative WPTs. It should be done in
a separate bug instead.
Differential Revision: https://phabricator.services.mozilla.com/D198345
`beforeinput` event shouldn't be fired if it's caused by JS. However, we
dispatch it when the call is by chrome script or an addon because there is
no user input emulation API for WebExtension and builtin editors make the
change undoable only when JS changes the editor value with
`Document.execCommand`. Therefore, addons may want to use
`Document.execCommand` for making the change undoable.
On the other hand, nested calls of `Document.execCommand` makes the error
handlings in editor classes too complicated. Therefore, we don't allow that.
However, this causes that if web apps intercept `beforeinput` events and
prevents the default and calls `document.execCommand`, the first call of
web apps may be first nested call if the `beforeinput` event is caused by
a call of `Document.execCommand` in addon.
Therefore, this patch makes `Document` stores whether `ExecCommand` is called
by content or chrome/addon. And if the call is improperly nested, keep stopping
handling the command, but allows if and only if the first call is by
chrome/addon.
Differential Revision: https://phabricator.services.mozilla.com/D198357
When a context loss occurs on DrawTargetWebgl, this may result in a fallback TextureData
being created. Each of these are currently managed by two different RemoteTextureOwnerClients.
This is not really safe at all.
To fix this, CopyToSwapChain is modified so that it can be supplied a RemoteTextureOwnerClient.
Then CanvasTranslator can inject its own RemoteTextureOwnerClient into CopyToSwapChain, rather
than letting CopyToSwapChain use its own separate internal RemoteTextureOwnerClient.
This also tries to address a few other data consistency bugs with the fallback TextureData.
Differential Revision: https://phabricator.services.mozilla.com/D198487
Linux 4.17 applied some Spectre mitigations (SSBD and STIBP) by default
when seccomp-bpf is used, but later Linux 5.16 turned them off with
the rationale that, essentially: the attacks aren't really practical,
there are similar or worse attacks that it doesn't stop, and the
performance cost on is significant (STIBP seems to make indirect
branches unpredictable). Given that we support Linux distributions in
the affected range (e.g., Ubuntu 20.04 LTS, but not 22.04), and the
performance hit is very noticeable at least in microbenchmarks, this
patch opts out of the mitigations.
Note that, if a seccomp policy is applied by some external sandbox which
doesn't use this opt-out (e.g., if using Snap or Flatpak), and the
kernel is in that range, these Spectre mitigations will still be applied
and we can't turn them off.
Differential Revision: https://phabricator.services.mozilla.com/D198217
Per the documentation the system should handle `arguments=dismiss` to fire dismiss event but somehow it still fires activate event. This patch thus handles it manually while still taking advantage of the Windows provided localization of the button.
Differential Revision: https://phabricator.services.mozilla.com/D198286