The background hang monitor uses the same timing thresholds as the one used by
the compositor thread, for similar reasons.
Differential Revision: https://phabricator.services.mozilla.com/D120117
Instead of warning against callers directly accessing the thread message loop,
actuually prevent them from doing so. This is also a preliminary step to
changing the type of the internally-created thread, which will no longer
directly expose its message loop.
Differential Revision: https://phabricator.services.mozilla.com/D119562
Ensure firing the onStateChange on the BrowsingContext's WebProgress
of the page we navigate *from* instead of the one we navigate *to*.
(which was what used to happen before fission/bfcacheInParent)
Differential Revision: https://phabricator.services.mozilla.com/D119648
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
Automatic update from web-platform-tests
Fix flaky test layout-instability/input-timestamp.html
layout-instability/input-timestamp.html test is flaky because we are
waiting for 500ms to change the layout after a click event. The click
event should report a layout shift entry to PerformanceObserver with
hadRecentInput to be true, the layout shift of the div will report
another layout shift entry to PerformanceObserver with hadRecentInput to
be false. 500ms is the interval of the excluding input window, so if we
just set the timeout to be 500ms, the test is flaky, because the click
event may not executed right away. I change the time delay to be 600ms
to reduce the flakiness.
Bug: 1221422
Change-Id: Ib960d98fe7ac7d0806a7152052465e9188afb2a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3032268
Reviewed-by: Annie Sullivan <sullivan@chromium.org>
Commit-Queue: Lan Wei <lanwei@chromium.org>
Cr-Commit-Position: refs/heads/master@{#902699}
--
wpt-commits: 56bf98c5c076670e7ef0d60f973c7061ca13cd1f
wpt-pr: 29693
Automatic update from web-platform-tests
[LayoutNG] More OOF writing mode fixes in multicol
1. Previously, we had used the writing mode of the CB when setting
up the NodeInfo in NGOutOfFlowLayoutPart. However, we want to use the
writing mode of the builder instead since the OOF will be laid out
inside the fragmentainer children of the builder rather than the CB
itself (in the case of fragmentation).
2. When creating the CB rect for inline CB's, the start offset that
was used was relative to the inline's containing block. However,
since the OOF is laid out inside the fragmentainers, we need to
convert the inline CB's rect to take the writing mode of the multicol
into account.
The added tests are similar to those added in CL:3025848, but they
apply block/inline insets rather than using the static position.
The tests added in CL:3025848 were moved to a common directory
as those added in this CL.
Bug: 1228746
Change-Id: I6073683137d3bf58eea8ce6f355321e75046fb50
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3032909
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#902447}
--
wpt-commits: 6ec8995cb9ae8922ca539ff2c6737f48142f7d03
wpt-pr: 29683
Automatic update from web-platform-tests
Update navigator.ink.requestPresenter() to use a dictionary param
requestPresenter took in two params, a String |type| and an Element
|presentationArea|. The goal of the |type| param was to enable
requestPresenter() to be easily extensible in the future for other types
of presenters.
However, in its current state, it is a no-op param. For this reason,
after some discussion ([1], [2], [3]) it has been decided that the API
should be updated to instead just use a dictionary param. This will
still be easily extensible in the future, but won't require a string
param until then.
[1]: https://github.com/WICG/ink-enhancement/issues/20
[2]: https://github.com/w3ctag/design-reviews/issues/473#issuecomment-876612377
[3]: https://groups.google.com/a/chromium.org/g/blink-dev/c/ZtqwKR_HIAE
Bug: 1052145
Change-Id: I9ef18a04ab150fff8c8f173bfa209e10d90781f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3027884
Reviewed-by: Daniel Libby <dlibby@microsoft.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Mario Bianucci <mabian@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#902434}
--
wpt-commits: 94a65991bc0a5e5300241d7e8b0c699484751e11
wpt-pr: 29679
Automatic update from web-platform-tests
Rename scrollbar-gutter "mirror" to "both-edges"
For clarity, the "mirror" value of the scrollbar-gutter property has
been renamed to "both-edges". The functionality remains the same.
CSS WG: https://github.com/w3c/csswg-drafts/issues/6349
Bug: 710214
Change-Id: I65683037e083f2edee21451f54a9ef34374d0988
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3026774
Reviewed-by: Philip Rogers <pdr@chromium.org>
Commit-Queue: Felipe Erias <felipeerias@igalia.com>
Cr-Commit-Position: refs/heads/master@{#902287}
--
wpt-commits: 43b8e825b9d0bd67f812c08618266e6501b6da6e
wpt-pr: 29671
Automatic update from web-platform-tests
[EyeDropper API] Update implementation to match explainer.
Explainer:
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EyeDropper/explainer.md
I2P: https://groups.google.com/a/chromium.org/g/blink-dev/c/cPTMI1i6d7I/
The explainer was updated to address the tag review:
- moved to a promise based design (EyeDropper.open() returns a
Promise<ColorSelectionResult>)
- renamed the selected color property to sRGBHex to make it clear that
the color is a string and it is in sRGB (this allows room for future
properties to be added)
For now a manual test has been added, more test coverage is going to be
added in follow-up CLs.
Bug: 897309
Change-Id: Ib3631b94ff43cd59ba1640f0c295e233f058383a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3027321
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: Ionel Popescu <iopopesc@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#902121}
--
wpt-commits: ca5841f2435a1042649c99cf736918ad88a71098
wpt-pr: 29661
Automatic update from web-platform-tests
Refactored scroll timeline tests to defaults to progress based testing.
Converted a few tests to be progress based and fixed a conversion bug in
animation.cc
Bug: 1216655
Change-Id: I0882800677a4af0863883d59970594ea27cfb582
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3025004
Commit-Queue: Jordan Taylor <jortaylo@microsoft.com>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#902091}
--
wpt-commits: c4241caddefcd03ccb77935f71f5d787740cfb75
wpt-pr: 29650
Automatic update from web-platform-tests
[LayoutNG] Relative offset for OOFs with inline CBs in a multicol
Relative offsets should be applied after fragmentation. Since we perform
layout for OOFs once they reach the fragmentation context root (if
applicable), we fail to apply any relative offsets at the correct time
in the case of inline containing blocks. See CL:2851595 for how this
was handled for the non-inline case.
The changes required to accomplish this for inline containing blocks
include:
1. We currently store an accumulated relative offset in
NGContainingBlock inside the OOF node, which is any relative offset from
the containing block to the fragmentation context root. We also need to
store an accumulated relative offset from the inline container to the
containing block in order to properly apply all relative offsets at the
time of fragmentation.
A new struct, NGInlineContainer, was added to the OOF node to hold the
inline container object and the accumulated relative offset to the
containing block.
2. A relative offset was also added to the InlineContainingBlockGeometry
struct so that we have access to the relative offset from #1 when
creating the ContainingBlockInfo for the inline container.
3. The way that relative offsets are applied to inlines, it didn't seem
straightforward to separate the relative offset from the normal
offset, like we had in CL:2851595. Instead, store the relative offset
for the inline and subtract it out from the OOF static position once
it reaches the containing block, and subtract it from the containing
block rect offset when determining the ContainingBlockInfo for the
inline container.
4. Store the total relative offset (from the inline container to the
fragmentation context root) in ContainingBlockInfo. This relative
offset will then be applied after fragmentation is complete for the OOF
as a result of CL:2851595.
Bug: 1079031
Change-Id: I7198fec4c01e05ca54c51b2f215569b75b0b869e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2995308
Commit-Queue: Alison Maher <almaher@microsoft.com>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#902060}
--
wpt-commits: 67a78f560e0e0ec601193aa78d7031937bce78f7
wpt-pr: 29548
Automatic update from web-platform-tests
Deflake playing-an-animation.html
The root cause of the flakiness seems to be a floating point
precision issue. This CL fixed it by introducing an epsilon.
Without this fix, I can repro the flakiness locally very easily.
With this fix, I have ran 1000 times with running 48 content
shell in parallel and there is no flake.
Bug: 1198515
Change-Id: I6eaddebe12bba5131ee340549f84b7b27b729c37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3027227
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#902034}
--
wpt-commits: a1cb55f97a641485a96cf61766cdf926775813d6
wpt-pr: 29665
Automatic update from web-platform-tests
Deflake WPT test: none.https.html
The failing subtest was identified by:
https://chromium-review.googlesource.com/c/chromium/src/+/3015334
This patch puts the culprit into its own file, and tries to make it work
reliably.
Bug: 1013596
Fixed: 1013596
Change-Id: Ie98b5554824cee35f1e9f671a9962ba993a8b674
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3021142
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Antonio Sartori <antoniosartori@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901978}
--
wpt-commits: d2a0a6a108413e945e253b0f0493e718637dce09
wpt-pr: 29649
Automatic update from web-platform-tests
Deflake popup-coop-by-sw-from-coop.https.html
Nobody has ever been able to reproduce the problem. It is apparently a
timeout. To fix this, the test is marked as "long" and every subtest are
run separately.
At best, this fixes the issue. At worst, this will give us useful
information: which subtest is the culprit.
Bug: 1151555
Change-Id: I4b62b1d6a96fed97458567b11d7301f60bf6fc77
Fixed: 1151555
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3030564
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Antonio Sartori <antoniosartori@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901959}
--
wpt-commits: c13cf37f470fb729335ac67d325de63669a1bf1a
wpt-pr: 29675
Automatic update from web-platform-tests
Revert "Composite multiple independent transform property animations"
This reverts commit 0dfc7e362b3a4fbe98b4dd0afc05206f4213fa69.
Reason for revert: perf regression (crbug.com/1229374)
Original change's description:
> Composite multiple independent transform property animations
>
> Previously, individual transform properties were lumped together with
> transform lists, and only a single transform could be composited. With
> this patch, we support multiple transforms as long as each affects a
> different property (transform, translate, rotate, or scale).
>
> Bug: 696374
> Change-Id: Id4da5da2fceb929bd5ddbffc04f9d63f9b85497a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3016295
> Reviewed-by: Robert Flack <flackr@chromium.org>
> Commit-Queue: Kevin Ellis <kevers@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#901495}
Bug: 696374
Change-Id: Ic15583885f754916c647363f7eaaf4c39e2072af
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3031641
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901930}
--
wpt-commits: 41c2a732e7a325c8705439894b567c30f2c4be64
wpt-pr: 29676
Automatic update from web-platform-tests
[VirtualKeyboard] Add Secure Context to VK interface.
Added SecureContext to VK interface as we don't want to show/hide VK
when the document isn't the active document and hasn't been
authenticated. Some tests that used to run on insecure context were
changed to now use secure context instead. Using secure context also
led to removal of some tests where we were manually injecting VK
events to the browser. The embedded test server usage causes the
input method initialized in the RWHVA to use the real input method
instead of the mock implementation.
WPT tests in crrev.com/c/2993938 cover those cases.
Spec: https://github.com/w3c/editing/blob/gh-pages/docs/virtualkeyboard/index.html
Bug: 856269
Change-Id: Ie4fa4c50a08e8d439b985e62beea4d9aa57f3e26
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3003699
Reviewed-by: Kent Tamura <tkent@chromium.org>
Reviewed-by: Keith Lee <keithlee@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Anupam Snigdha <snianu@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#901863}
--
wpt-commits: 35593dd1a0617be0adc6428fe0487b34398d28aa
wpt-pr: 29651
Automatic update from web-platform-tests
Add WPT for COEP inheritance in local scheme popups
This change adds a Web Platform Test checking inheritance of Cross
Origin Embedder Policy to local scheme popups.
Change-Id: I66b4122751622a7d3df7112741a9f86785446417
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2984561
Reviewed-by: Domenic Denicola <domenic@chromium.org>
Commit-Queue: Antonio Sartori <antoniosartori@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901853}
--
wpt-commits: f27bd064b94b35fb80dc389327b264bdbe11a7ae
wpt-pr: 29475
Automatic update from web-platform-tests
[SPC] Enable SPC API V2 features.
This patch enables SecurePaymentConfirmationAPIV2 flag by default in
M93. This flag controls a subset of features that are enabled by
SecurePaymentConfirmation flag, which is in origin trial between M91 and
M94. The changes in SecurePaymentConfirmationAPIV2 resulted from the
initial feedback from origin trial partners.
Blink-dev announcement:
https://groups.google.com/a/chromium.org/g/blink-dev/c/6Dd00NJ-td8/m/iXX4YilWEwAJ
Bug: 1210488
Change-Id: I80920c138b063b89682de2a5909bf88347bfd448
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3027027
Commit-Queue: Rouslan Solomakhin <rouslan@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Liquan (Max) Gu <maxlg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901845}
--
wpt-commits: 8e99531ef6ee1e3db50120b126bc07de682f1e0a
wpt-pr: 29669
Automatic update from web-platform-tests
[LayoutNG] OOF inline containing block writing-mode conversions
When we create the containing block rect based on the geometry
calculated in InlineContainingBlockUtils, we convert everything
against the entire containing block, including the block size from
all fragments. However, the start/end rects that are calculated
in InlineContainingBlockUtils are relative to a single containing
block fragment.
As a result, we can end up with incorrect offsets when performing
writing mode conversions on the containing block rect. To fix this,
convert the item offsets in InlineContainingBlockUtils such that they
are relative to the full containing block instead.
In addition to the writing-mode conversion improvements, it was
also observed that we weren't retrieving the previous containing
block break token in InlineContainingBlockUtils::
ComputeInlineContainerGeometryForFragmentainer() when there were
no split inlines. The reason being that we would continue to the
next CB fragment before updating the previous break token. This
logic is fixed by this CL, as well.
Bug: 1227115
Change-Id: I1039ef0c93ef928891c3b581399b3d3f1427d6b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3017280
Commit-Queue: Alison Maher <almaher@microsoft.com>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901795}
--
wpt-commits: 9aafe3aae6fda345c8ff9784058bae4fdbe645f9
wpt-pr: 29616
Automatic update from web-platform-tests
Initialize AudioData from BufferSource
This CL updated AudioDataInit to use a BufferSource data member, instead
of an AudioBuffer member. It also moves fields found in the AudioBuffer
into the top level AudioDataInit.
This allows users to create AudioData in whichever format they want.
Bug: 1205281
Change-Id: If234ace2d64e79470f6561c9c0838643ec390f8e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3025311
Commit-Queue: Thomas Guilbert <tguilbert@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901720}
--
wpt-commits: 0dd9d64da423eec530273f40dc14f0a4b4256f89
wpt-pr: 29653
Automatic update from web-platform-tests
[webcodecs] Emit AbortError for flushes that have been reset.
Previously these Promises were rejected with undefined, but the
appropriate object is an AbortError.
Bug: 1201299
Change-Id: I023c1107541ce7e809f769a3fa4d422c63dcdf83
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3027782
Commit-Queue: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901717}
--
wpt-commits: 9bc3decf66834c5656307b5efee7150c3cdd668b
wpt-pr: 29664
Automatic update from web-platform-tests
[LayoutNG] OOF static position with conflicting direction
We were always using the containing block's writing mode when
converting the static position because we want the offset to be
relative to the CB. However, this resulted in an incorrect offset
when the multicol had a different direction. Instead of always
using the CB's writing mode when converting the static position, use
the current fragment's writing mode.
The added tests are based on their non-multicol counterparts. Some
of the tests passed previously if there was no writing mode mismatch.
Bug: 1228746
Change-Id: I2027ccd7c384a75f54d8dc5833de775f3ab7e58c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3025848
Commit-Queue: Alison Maher <almaher@microsoft.com>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901570}
--
wpt-commits: 11f387786eb70d8a846e6d4c4e1bf32dde4bac22
wpt-pr: 29657
Automatic update from web-platform-tests
[counter-style] Add a test for styling list markers via shadow DOM part
Note: this test case is the same as example FOUR in
https://github.com/w3c/csswg-drafts/issues/1995#issue-275014458
Bug: 1225033
Change-Id: Ic02c6c0e9c623c4eb12ac4bc152716f63f6ebd52
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3025847
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#901552}
--
wpt-commits: 0993872f0a326817e4acb9b462930517816f82c4
wpt-pr: 29662
Michael Cooper
Csoregi Natalia
Brad Werth
Shane Caraveo
Ben Hearsum
Sam Foster
Kajal Sah
Thomas Wisniewski
Alexandre Poirot
Andreea Pavel
Alex Lopez
moz-wptsync-bot
Lan Wei
Yifan Luo
Alison Maher
Mario Bianucci
Ian Kilpatrick
Daniel Vogelheim
Felipe Erias
Ionel Popescu
Jordan Taylor
Xida Chen
Arthur Sonzogni
Kevin Ellis
Eugene Zemtsov
Anupam Snigdha
Antonio Sartori
Dale Curtis
Rouslan Solomakhin
Thomas Guilbert
Dan Sanders
Xiaocheng Hu