The query method already validates whether access to private cookies is
allowed. It cannot yield private cookies if not allowed, so checking it
again in the loop of getAll is redundant..
Differential Revision: https://phabricator.services.mozilla.com/D127644
Move the duplicate logic of parsing the storeId to a common place.
This patch has the following observable change in behavior:
- Invalid storeId (whether with the "firefox-container-" prefix or with
something else) have the same error message instead of distinct ones.
Instead of "Illegal storeId: X` or "Unknown storeId", the message is
now `Invalid cookie store id: "X"`, which is also what Chromium uses.
Differential Revision: https://phabricator.services.mozilla.com/D127643
The cookies API implementation emits a bunch of errors in some cases,
but these are not covered by unit tests. I'm going to refactor some
logic involving these checks, and before doing so I'd like to start
with unit tests with the current behavior as expectations.
Differential Revision: https://phabricator.services.mozilla.com/D127642
Automatic update from web-platform-tests
[flex] Clamp available sizes to zero.
Scrollbars may be present on a box. When subtracting
BorderScrollbarPadding we almost always need to clamp to zero, as the
border-box size - bsp may be negative.
Bug: 1274476
Change-Id: I55322f5c5bc5a5bbe9fefc1eb1403677044b9443
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3307128
Reviewed-by: Alison Maher <almaher@microsoft.com>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946104}
--
wpt-commits: 9811accad612849822802ab82e168a198cd89805
wpt-pr: 31780
Automatic update from web-platform-tests
Prevent opaque range request responses from entering the preload cache
ResourceLoader cancels range request responses that were not initiated
with range request headers causing them to error out and be cleared from
the preload cache. Other responses (200, 416, error, etc) complete
successfully and would otherwise enter the preload cache, making them
observable.
This prevents opaque range responses of any kind from persisting in the
preload cache (which would not naturally have any anyway).
Bug: 1270990
Change-Id: Ife9922fe0b88e39722f3664ddd091a1516892157
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3294001
Reviewed-by: Ben Kelly <wanderview@chromium.org>
Reviewed-by: Yoav Weiss <yoavweiss@chromium.org>
Commit-Queue: Patrick Meenan <pmeenan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946055}
--
wpt-commits: 5fc81f8eaa41bf9ea8ffb9a0869c426a02ff2f64
wpt-pr: 31720
Automatic update from web-platform-tests
Reduce flakiness of COOP tests by using timeouts (#31725)
The COOP WPTs requiring a popup to be navigated were waiting before
navigating:
- that the onload event triggered
- requestAnimationFrame was executed, twice.
The latter is not always executed when the tab doesn't have the focus,
and gets executed as soon as it gets it. As an alternative, we added a
timeout, which avoids waiting for too long. It still achieves the same
goal in the tests I conducted than requestAnimationFrame: Make sure the
navigation is not considered as a redirection, and that a history entry
is created as a result.
Bug: 1233840
Change-Id: I5c8bbbccdc9b76ec32c795e7f5a4cdc594823e27
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3297849
Auto-Submit: Pâris Meuleman <pmeuleman@chromium.org>
Commit-Queue: Pâris Meuleman <pmeuleman@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945351}
Co-authored-by: Pâris Meuleman <pmeuleman@chromium.org>
--
wpt-commits: 71a9256b1f56ade260091cd6f62644970c8a42d4
wpt-pr: 31725
Automatic update from web-platform-tests
[Private Network Access] Write Web Platform Tests for preflights.
- Introduce a new preflight.py wptserve request handler that can respond
to CORS and PNA preflight requests, as well as follow-up requests.
- Update existing tests to use this endpoint correctly for CORS headers.
- Add new tests that exercise PNA preflight behavior, checking that the
correct headers must be set on the preflight response.
- Add a virtual test suite to exercise these tests with preflights
enabled and enforced. For now, many tests fail at HEAD outside the
virtual test suite.
Fixed: chromium:1268876
Change-Id: Idb2bc4a216c75f963aa6f190d542a2eb6d6f4a7d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3302789
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Arthur Hemery <ahemery@chromium.org>
Commit-Queue: Titouan Rigoudy <titouan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945972}
--
wpt-commits: ef0854594cfe20045ddfcf86697c92b43f113657
wpt-pr: 31747
Automatic update from web-platform-tests
Reland "Initial support for text-decoration-line: spelling|grammar-error"
This is a reland of 643df2d079fac73cb420e6cd074c79d5a739f63d
It missed rebaselines for Mac 10.12.
Original change's description:
> Initial support for text-decoration-line: spelling|grammar-error
>
> This adds the initial support for spelling-error and grammar-error
> values of text-decoration-line property.
>
> Main changes are in TextDecorationInfo, where we need to support
> the new values and paint the decoration correctly.
> In Mac platform we use a dotted decoration to match
> the platform conventions.
> In other platforms we use a wavy decoration, but we modify it
> so it looks similar to the spelling and grammar markers
> in Microsoft Word.
>
> It's important to note that this is just an intermediate step,
> as this is different than how we currently paint
> the spelling and grammar errors in DocumentMarkerPainter.
> The idea would be make DocumentMarkerPainter use CSS text decorations
> and then use this new code added here.
>
> There are some known issues:
> * The underline offset is not the same than in Microsoft Word,
> but that's because of a problem with regular underlines
> not using the font metrics to compute that offset (crbug.com/1273042).
> * We should allow to tweak the color with text-decoration-color,
> added a TODO about that.
>
> BUG=1163436
>
> Change-Id: I117ad38fe3fc805619eb47b1df2f48c9d7c9a351
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3297885
> Commit-Queue: Delan Azabani <dazabani@igalia.com>
> Reviewed-by: Delan Azabani <dazabani@igalia.com>
> Reviewed-by: Stephen Chenney <schenney@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#945876}
Bug: 1163436
Change-Id: I8c719644a611fef901ad60e25aa19f5b53ce199e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3306472
Reviewed-by: Delan Azabani <dazabani@igalia.com>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Manuel Rego <rego@igalia.com>
Cr-Commit-Position: refs/heads/main@{#945958}
--
wpt-commits: 26d2cfcf89582cff18696e8ce37d05469d68323c
wpt-pr: 31775
Automatic update from web-platform-tests
Revert "Initial support for text-decoration-line: spelling|grammar-error"
This reverts commit 643df2d079fac73cb420e6cd074c79d5a739f63d.
Reason for revert: text-decoration-line-grammar-error.html and text-decoration-line-spelling-error.html fail consistently on Mac10.12 Tests
Original change's description:
> Initial support for text-decoration-line: spelling|grammar-error
>
> This adds the initial support for spelling-error and grammar-error
> values of text-decoration-line property.
>
> Main changes are in TextDecorationInfo, where we need to support
> the new values and paint the decoration correctly.
> In Mac platform we use a dotted decoration to match
> the platform conventions.
> In other platforms we use a wavy decoration, but we modify it
> so it looks similar to the spelling and grammar markers
> in Microsoft Word.
>
> It's important to note that this is just an intermediate step,
> as this is different than how we currently paint
> the spelling and grammar errors in DocumentMarkerPainter.
> The idea would be make DocumentMarkerPainter use CSS text decorations
> and then use this new code added here.
>
> There are some known issues:
> * The underline offset is not the same than in Microsoft Word,
> but that's because of a problem with regular underlines
> not using the font metrics to compute that offset (crbug.com/1273042).
> * We should allow to tweak the color with text-decoration-color,
> added a TODO about that.
>
> BUG=1163436
>
> Change-Id: I117ad38fe3fc805619eb47b1df2f48c9d7c9a351
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3297885
> Commit-Queue: Delan Azabani <dazabani@igalia.com>
> Reviewed-by: Delan Azabani <dazabani@igalia.com>
> Reviewed-by: Stephen Chenney <schenney@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#945876}
Bug: 1163436
Change-Id: I2622bde37f2f8a7f725a1a06be8d34acdf9f728b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3306392
Auto-Submit: Greg Thompson <grt@chromium.org>
Owners-Override: Greg Thompson <grt@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#945903}
--
wpt-commits: 0b044312ec1d3dc5a91ab6701276fcacaca04836
wpt-pr: 31774
Automatic update from web-platform-tests
Initial support for text-decoration-line: spelling|grammar-error
This adds the initial support for spelling-error and grammar-error
values of text-decoration-line property.
Main changes are in TextDecorationInfo, where we need to support
the new values and paint the decoration correctly.
In Mac platform we use a dotted decoration to match
the platform conventions.
In other platforms we use a wavy decoration, but we modify it
so it looks similar to the spelling and grammar markers
in Microsoft Word.
It's important to note that this is just an intermediate step,
as this is different than how we currently paint
the spelling and grammar errors in DocumentMarkerPainter.
The idea would be make DocumentMarkerPainter use CSS text decorations
and then use this new code added here.
There are some known issues:
* The underline offset is not the same than in Microsoft Word,
but that's because of a problem with regular underlines
not using the font metrics to compute that offset (crbug.com/1273042).
* We should allow to tweak the color with text-decoration-color,
added a TODO about that.
BUG=1163436
Change-Id: I117ad38fe3fc805619eb47b1df2f48c9d7c9a351
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3297885
Commit-Queue: Delan Azabani <dazabani@igalia.com>
Reviewed-by: Delan Azabani <dazabani@igalia.com>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945876}
--
wpt-commits: 3ee257b18ef0fcb1c6346c9d3b760922b26673c6
wpt-pr: 31727
Automatic update from web-platform-tests
Add tests for letterspacing and wordspacing with different units
After changing letterspacing and wordspacing to accept strings,
test if they work with different length units, ex: px, mm, cm, inch, em.
Bug: 1263632
Change-Id: I2944ff56e1bfd796b0c6481d7f0f67775d9ce8b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3297936
Commit-Queue: Yi Xu <yiyix@chromium.org>
Reviewed-by: Juanmi Huertas <juanmihd@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945872}
--
wpt-commits: d613c3c794c784a2c6116c586422cc13cfc9d505
wpt-pr: 31735
Automatic update from web-platform-tests
SVG Text NG: Fix an issue of multiple continuous <textPath>
We failed to get the PathPositionMapper for the latter <textPath>
if multiple <textPath> are placed continuously.
Bug: 1274425
Change-Id: I539e987c32b35b8a4596de6aad8d4b724448fd4d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3305145
Auto-Submit: Kent Tamura <tkent@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945861}
--
wpt-commits: ae61df6244676bb25d6a6256b7aeffbe1900090e
wpt-pr: 31769
Automatic update from web-platform-tests
URL: Add test with invalid punycode (contains non-ASCII character) (#31767)
To test if URL parser is affected by ICU-21212 bug:
https://unicode-org.atlassian.net/browse/ICU-21212
Bug was fixed in ICU 68.1 version. In the earlier ICU versions the
`uidna_nameToASCII` function reports no error on this input, and returns
the same string as input.
--
wpt-commits: b772ca18865a09f3307440a9a756cb08fc0028a6
wpt-pr: 31767
Automatic update from web-platform-tests
Fix absolute-position under non-containing stacking context
When a stacking context has non-contained absolute-position descendant,
and the stacking context is forced by its ancestor to update cull rect,
the stacking context needs to propagate the forced cull rect update
flag to descendants because the cull rect of non-contained
absolute-position descendant depends on the contents cull rect of its
container instead of the non-containing stacking context.
Bug: 1273431
Change-Id: I8155df211fd4781c1c97f25302d2ebd22c3e8309
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3302093
Auto-Submit: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#945771}
--
wpt-commits: 7066b521e6f243238590f6242a123a841f22dcc6
wpt-pr: 31752
This patch adds a new toolchain run property: toolchain-env which allows
specifying additional environment variables that will be added to the worker
when consuming the toolchain artifact.
Differential Revision: https://phabricator.services.mozilla.com/D131987
We already use the adoptopenjdk on some platforms, this allows us to have a
more predictable Java binary on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D130878
This patch adds a test to ensure that a dedicated worker can be created
in a page which is controlled by a servcie worker.
Differential Revision: https://phabricator.services.mozilla.com/D132371
We should use the parititoned principal when creating clientSource in
WorkerPrivate if the workerPrivate is in third-party context.
Differential Revision: https://phabricator.services.mozilla.com/D132370
This patch enables partitioned service workers in third-party contexts.
Doesn't like before, we will allow service workers to be registered even
the third-party contexts don't have storage access and the registered
service workers will be partitioned by the top-level site.
You can control this by using the pref 'privacy.partition.serviceWorkers'.
Setting this to true will enable the partitioning, otherwise, it will
still use the old behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131788
Keeping the pref as signed, since the existing code explicitly handles that case, so someone may have -1 as the pref value.
Differential Revision: https://phabricator.services.mozilla.com/D132020
The query method already validates whether access to private cookies is
allowed. It cannot yield private cookies if not allowed, so checking it
again in the loop of getAll is redundant..
Differential Revision: https://phabricator.services.mozilla.com/D127644
Move the duplicate logic of parsing the storeId to a common place.
This patch has the following observable change in behavior:
- Invalid storeId (whether with the "firefox-container-" prefix or with
something else) have the same error message instead of distinct ones.
Instead of "Illegal storeId: X` or "Unknown storeId", the message is
now `Invalid cookie store id: "X"`, which is also what Chromium uses.
Differential Revision: https://phabricator.services.mozilla.com/D127643
Rob Wu
moz-wptsync-bot
Ian Kilpatrick
Patrick Meenan
Blink WPT Bot
Titouan Rigoudy
Manuel Rego Casasnovas
Greg Thompson
dependabot[bot]
Yi Xu
Kent Tamura
BruceDai
Rimas Misevičius
Xianzhu Wang
Agi Sferro
Tooru Fujisawa
Mark Striemer
Kagami Sascha Rosylight
Steve Fink
pestanoah
Emilio Cobos Álvarez
Butkovits Atila
Tim Huang
Cosmin Sabou
Olli Pettay