Those preferences got updated to "app.normandy.*" with Firefox 60, and are no longer necessary to be set.
Differential Revision: https://phabricator.services.mozilla.com/D45576
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
Differential Revision: https://phabricator.services.mozilla.com/D46642
--HG--
extra : moz-landing-system : lando
Also, update the serialization by the shorter perference because this is
a new feature and using older syntax doesn't make sense.
Besides, use `cssOffset` for web animation IDL attribute name.
Differential Revision: https://phabricator.services.mozilla.com/D45607
--HG--
extra : moz-landing-system : lando
We compare two file ids to check the current process is launched from the same
executable. However, our telemetry showed a number of Win7 users failed to open
a file handle of the parent process with STATUS_OBJECT_PATH_NOT_FOUND even
though we opened a process handle and retrieved a module path of the parent
process successfully. We don't have data to explain how this happens or why
this happens only on Win7, Win10 10240, and 10586.
To mitigate this situation, this patch introduces a logic to compare NT path
strings. The benefit from doing this is 1) we don't have to open a file handle
of a parent process executable and 2) when we get an NT path, a network drive
or a symbolic link is already solved.
This new logic is much faster, but we still compare file ids on the first
attempt to minimize the impact. We fall back to the new logic only if we
detect the STATUS_OBJECT_PATH_NOT_FOUND failure.
Differential Revision: https://phabricator.services.mozilla.com/D45476
--HG--
extra : moz-landing-system : lando
Stop running all Raptor tests that run against Fennec. Raptor tests running
against geckoview and geckoview products continues.
Differential Revision: https://phabricator.services.mozilla.com/D44511
--HG--
extra : moz-landing-system : lando
Our implementation modified the state, in addition to throwing the exception.
And the tests not only didn't test for this, but wouldn't have reached that
code anyway, due to the harness giving up as soon as anything failed.
Differential Revision: https://phabricator.services.mozilla.com/D46106
--HG--
extra : moz-landing-system : lando
Tasks dispatched from RunInStableState() can be cancelled if there's a load in
between, so this is not sound.
See nsSyncSection::IsCancelled().
This is the only patch in this bug that is worth uplifting IMO.
Differential Revision: https://phabricator.services.mozilla.com/D46773
--HG--
extra : moz-landing-system : lando
This test assumes that the initial value of `border-image-outset` is '0px' but it is '0'.
'0' does not interpolate with '2px' in a <number> | <length> context since it is treated
as a <number> per spec.
This issue arose because Blink treats the initial value of `border-image-outset` as '0px'.
This is a known bug: https://crbug.com/898203
Differential Revision: https://phabricator.services.mozilla.com/D46722
--HG--
extra : moz-landing-system : lando
As they were in the original patch for this bug, and is the only
*-interpolation.html bit that remains with these annotations.
MANUAL PUSH: Tentative Tier2 bustage fix.
This patch fixes a number of issues with the common interpolation testing
functions upstreamed from Blink.
Firstly this test file sets an animation duration of 2,000,000,000s and a delay
of -1,000,000,000s but that does not appear to be necessary since no time
elapses between when the animation is established and when the result is
checked (measure() is called immediately after interpolate() without any
interleaving call to requestAnimationFrame, for example).
Furthermore, this long time will cause some configurations of Firefox on
Windows to treat the time as an infinite time and end up producing discrete
animation. There is nothing in CSS values that requires supporting times of
this magnitude (~63 years) so it seems best not to make the tests rely on it
being supported (the tests are intended to cover interpolation after all, not
timing range) and instead to use a shorter time.
Similarly, for the Web Animations interpolation tests, this utility function
uses a duration of 1ms and seeks to 0.5ms. This can likewise lead to precision
issues, particularly when testing interpolation pairs that fall back to
discrete animation since in that case, the test will seek to precisely 0.5ms
and test that the result is at the top of the step that occurs at that time.
Floating-point error can cause this to fail so this patch changes the duration
and seek time to 100s and 50s respectively.
This patch also includes a few additional tweaks to this file including:
* Replacing the "steps(2, end)" timing function with "linear" since this
avoids floating-point errors at the 0.5 mark.
* Adding translation for "float" to "cssFloat".
* Triggering transitions by querying the property being transitioned.
(In theory a UA could skip flushing all styles when accessing the 'left'
property but in practice that is probably not Web-compatible.)
Differential Revision: https://phabricator.services.mozilla.com/D46698
--HG--
extra : moz-landing-system : lando
This patch fixes a number of issues with the common interpolation testing
functions upstreamed from Blink.
Firstly this test file sets an animation duration of 2,000,000,000s and a delay
of -1,000,000,000s but that does not appear to be necessary since no time
elapses between when the animation is established and when the result is
checked (measure() is called immediately after interpolate() without any
interleaving call to requestAnimationFrame, for example).
Furthermore, this long time will cause some configurations of Firefox on
Windows to treat the time as an infinite time and end up producing discrete
animation. There is nothing in CSS values that requires supporting times of
this magnitude (~63 years) so it seems best not to make the tests rely on it
being supported (the tests are intended to cover interpolation after all, not
timing range) and instead to use a shorter time.
Similarly, for the Web Animations interpolation tests, this utility function
uses a duration of 1ms and seeks to 0.5ms. This can likewise lead to precision
issues, particularly when testing interpolation pairs that fall back to
discrete animation since in that case, the test will seek to precisely 0.5ms
and test that the result is at the top of the step that occurs at that time.
Floating-point error can cause this to fail so this patch changes the duration
and seek time to 100s and 50s respectively.
This patch also includes a few additional tweaks to this file including:
* Replacing the "steps(2, end)" timing function with "linear" since this
avoids floating-point errors at the 0.5 mark.
* Adding translation for "float" to "cssFloat".
* Triggering transitions by querying the property being transitioned.
(In theory a UA could skip flushing all styles when accessing the 'left'
property but in practice that is probably not Web-compatible.)
Differential Revision: https://phabricator.services.mozilla.com/D46698
--HG--
extra : moz-landing-system : lando
Automatic update from web-platform-tests
Add missing module descendant test
This CL adds a web-platform-test for a page with a remote-origin module
script that loads a descendant script that is same-origin with the page.
The test asserts that the referrer header for the descendant is
generated correctly for pages with the policies `no-referrer`,
`same-origin`, `origin-when-cross-origin`, `unsafe-url`.
The tests were originally a part of crrev.com/c/1786260, however given
the complications with the CL and the necessity of these tests, I am
landing them separately.
R=kouhei@chromium.org, nhiroki@chromium.org, yhirano@chromium.org
Bug: 786862,1004083
Change-Id: I8768e5a4b23c75b72c4befdbacff717c0d5296c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1809205
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/master@{#698083}
--
wpt-commits: 7b32d10755803a1413ae7813f157906bad31525e
wpt-pr: 19163
Automatic update from web-platform-tests
Implement word boundary matching
Ensure a match is bounded by word boundaries. This implementation uses a
similar approach to providing FindOptions::kWholeWord to
FindBuffer::FindMatchInRange, however that option requires the search
text to be a single word.
Added tests and a web platform test case.
Bug: 924965
Change-Id: Iaa6785181eb29f0d25f64026c3be05d095ace3ad
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1803723
Commit-Queue: Nick Burris <nburris@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#697244}
--
wpt-commits: 1ce7ac3fe7437a3a58ac71b3e3304f0b15cb1d13
wpt-pr: 19049
Automatic update from web-platform-tests
Revert "Re-land: Fix `Referer` for descendant module scripts and worklets" (#19088)
This reverts commit c99349614d37ba823fdab9532cddd269d56d8436.
Reason for revert: This CL was causing DumpWithoutCrashes that we’re
currently working to debug. See https://crbug.com/1004083 for more
details.
Original change's description:
> Re-land: Fix `Referer` for descendant module scripts and worklets
>
> This CL addresses a problem with SecurityPolicy::GenerateReferrer
> when it comes to checking the same-origin-ness of a request. The
> WebAppSec Referrer Policy Standard defines a same-origin request [1] as
> one where the request's origin and current URL are same-origin with
> each other. This comparison is done in "determine a request's referrer"
> algorithm.
>
> The analogous place in our implementation is
> SecurityPolicy::GenerateReferrer. Before this CL, GenerateReferrer would
> determine a request's same-origin-ness by comparing the origin of the
> request's referrer string and the origin of the request's current URL.
> Most of the time this was sufficient, as the request's referrer string
> is almost always same-origin with the request's origin (initiator
> in Blink). With descendant module scripts and worklets however, the
> origin of the request's referrer string and request's origin (initiator)
> could be different, which breaks the correctness of our GenerateReferrer
> method.
>
> This CL introduces a blink::SecurityOrigin parameter to the
> GenerateReferrer method, so that correct same-origin comparisons can be
> carried out. In all GenerateReferrer call-sites, an appropriate origin
> is passed in.
>
> The original CL [2] was reverted because the semantics of
> SecurityPolicy::GenerateReferrer were not kept in sync with the similar
> logic in net::URLRequestJob::ComputeReferrerForPolicy, which caused a
> DumpWithoutCrashing bug seen in https://crbug.com/1000614, and request
> cancellations. This reland updates the ComputeReferrerForPolicy logic
> to match the corresponding Blink logic, and includes documentation
> mentioning that changes to one section should be reflected in the other.
> This CL also includes web platform tests for the scenario in the
> aforementioned bug, which pass with this CL, as well as net unit tests
> for RedirectInfo and URLRequestJob.
>
> [1]: https://www.w3.org/TR/referrer-policy/#same-origin-request
>
> [2]: https://crrev.com/c/1768501
>
> Bug: 786862
> Change-Id: I1deeaae8191b07856c593ddb2486297344e0b846
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1786260
> Commit-Queue: Dominic Farolino <dom@chromium.org>
> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
> Reviewed-by: Benoit L <lizeb@chromium.org>
> Reviewed-by: Matt Menke <mmenke@chromium.org>
> Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
> Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
> Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
> Reviewed-by: Tarun Bansal <tbansal@chromium.org>
> Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#695523}
TBR=kinuko@chromium.org,yhirano@chromium.org,caseq@chromium.org,kouhei@chromium.org,mmenke@chromium.org,nhiroki@chromium.org,tbansal@chromium.org,lizeb@chromium.org,dom@chromium.org
Change-Id: I3d812f99e3a2e6cb6b8d56a78580273cf266a22f
No-Presubmit: true
No-Tree-Checks: true
Bug: 786862
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1806618
Commit-Queue: Dominic Farolino <dom@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Cr-Commit-Position: refs/heads/master@{#696813}
--
wpt-commits: 054c94d81c771e79c77744205126865d02ad6fc9
wpt-pr: 19088
Automatic update from web-platform-tests
Make the has_operator_spacing detection more reliable. (#19138)
It seems the 10px error is too small for very large font-size.
--
wpt-commits: 59d5350b143cbb45c8a80704ea7cd3d3a5341a69
wpt-pr: 19138
Automatic update from web-platform-tests
[webnfc] Add test for calling push() twice (#19155)
* [webnfc] Add test for calling push() twice
A push should replace all previously configured push operations.
--
wpt-commits: a3a4442b04c37155f81c4ad4ae9c06339f76ce14
wpt-pr: 19155
Automatic update from web-platform-tests
Initial Storage Access API IDL Changes
This change adds the initial surface area for the methods and sandbox token exposed by the Storage Access API behind the storageAccessAPI runtime flag. Initially the promises created will return simple/immediate resolutions or rejections. Future changes will update the logic of each method to ensure it is functioning correctly. Additionally Web Platform Tests have been added to validate the added behaviour.
As the newly added tests rely on running tests within iFrames an exposed bug in the content_shell testrunner JS has been fixed. The change ensures that iframes will not complete the testharness and that only the main frame will trigger completion.
Bug: 989663
Change-Id: I2388fbc25ceb95c49435aa986191b0aca925d7d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1790583
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Brandon Maslen <brandm@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#697926}
--
wpt-commits: 423c19a36e9ccf2f212d2af31031bfb02febd454
wpt-pr: 18951
Automatic update from web-platform-tests
Give more context for the /gen/ lint rule
The purpose is to avoid adding more exceptions without careful consideration.
--
wpt-commits: 3515be34aff6a81441b3d1a7fc34b55f6edcbf2c
wpt-pr: 19152