Disabling `MOZ_DATA_REPORTING` results in the `PREF_UPLOAD_ENABLED` pref not
being loaded with `Preferences.add`. This means
`Preferences.get(PREF_UPLOAD_ENABLED)` can possibly be `null`, which was
previously not handled and resulted in an error for the whole privacy.js file.
So only call `dataCollectionCheckboxHandler` for the `privateAttribution`
checkbox if `MOZ_DATA_REPORTING` is enabled (otherwise the `privateAttribution`
checkbox also just doesn't exist). Also move the call into separate
`initPrivateAttributionCheckbox` function to be more consistent with previous
code.
Differential Revision: https://phabricator.services.mozilla.com/D218265
After updating the Widevine plugin to 4.10.2830.0, we would crash on
startup of the plugin because it attempted to use the stat syscall.
Allow uses of stat for files that we have already opened / allowed
access to in the GMP sandbox.
Differential Revision: https://phabricator.services.mozilla.com/D218855
This patch switches the main logic from a boolean pref to an integer with different feature modes.
See nsIBounceTrackingProtection for the new modes supported. Dry-run mode has been merged into the mode
pref.
A new state is introduced MODE_ENABLED_STANDBY in which BTP still collects user activation signals, but
does not classify or purge bounce trackers. This new mode should be used when it's expected that the
feature may be toggled on/off after rollout. Collecting user activation even in the "disabled" state
ensures that when the feature gets re-enabled the user activation map is already warmed up and sites
important to the user are not classified + purged.
The BounceTrackingProtection singleton listens for changes on the mode pref and inits / tears down accordingly.
However it never shuts down fully. To fully disable the feature a restart is required.
Differential Revision: https://phabricator.services.mozilla.com/D217848
The background image is associate to the table frame, but the table wrapper frame is the primary frame, thus IsPrimaryFrameOfRootOrBodyElement returns false and we don't propagate to the root when we should. So I changed IsPrimaryFrameOfRootOrBodyElement to handle this case and renamed it. I checked the other root element frame types, only table frames had this issue.
Differential Revision: https://phabricator.services.mozilla.com/D217923
Automatic update from web-platform-tests
Replace option-arbitrary-content <selectlist> tests
This patch deletes some <selectlist> tests which test the arbitrary
rendering of <option>s. This behavior is already tested by the following
tests:
select-child-button-and-datalist-invalidation.tentative.html
select-child-button-and-datalist.tentative.html
select-open-invalidation.tentative.html
The deleted tests also test that images are rendered and that the
arbitrary rendering still works after the <option> is removed and
re-appended, so I added a new reftest which tests for these.
Fixed: 338513292
Bug: 335458492
Change-Id: Id1d5e1ffcfe9d2adecaada7188198fb933eca5c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5767634
Reviewed-by: Traian Captan <tcaptan@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1339276}
--
wpt-commits: f0414120abca52a08f73edb511952597b8bed9c1
wpt-pr: 47521
Automatic update from web-platform-tests
Delete selectlist-parts-structure test
- "HTMLOptionElements (and not other element types) should receive
option controller code" is not needed because the behavior attribute
no longer exists.
- "To receive option part controller code, an option must be a
descendant of the listbox part in a flat tree traversal" is no longer
relevant because it isn't possible to render a descendant <option>
outside of the listbox.
- "To receive button part controller code, an element labeled as a
button must not be a descendant of the listbox part in a flat tree
traversal" is not relevant anymore because the behavior attribute is
gone and there is no other way of explicitly labeling a button as the
button which opens the listbox.
- "To receive listbox part controller code, an element labeled as a
listbox must not be a descendant of the button part in a flat tree
traversal" is not relevant anymore because there is no behavior
attribute or other way of specifying which <datalist> is the listbox.
- "Button controller code should be applied in flat tree traversal order
regardless of dynamic insertion order" is not relevant anymore because
we aren't using flat tree traversals anymore.
- "Listbox controller code should be applied in flat tree traversal
order regardless of dynamic insertion order" is not relevant anymore
because we aren't using flat tree traversals anymore.
- "selected-value controller code should be applied in flat tree
traversal order regardless of dynamic insertion order" isn't relevant
anymore because we aren't using flat tree traversals anymore.
- "Ensure that controller code is applied when slot and part attributes
are different" isn't relevant anymore since we aren't using slot or
part attributes anymore.
- "Ensure that controller code is synchronously applied" isn't relevant
anymore since we don't have the behavior attribute anymore.
- "Controller code should be updated when nested parts are removed"
isn't relevant anymore since there is not behavior attribute and there
is otherwise no way to nest the relevant elements which would get
behaviors applied to them.
- "Moving a selectlist between documents should keep controller code
active" is not relevant because we aren't listening to lifecycle
events which need to be transferred to the new document and the async
MutationObserver which <option> elements are using don't seem to need
any special handling to be moved to the new document either.
- "New parts should be detected even when in the subtree of an inserted
node" is not relevant anymore because we don't have the behavior
attribute anymore.
Bug: 335458492
Fixed: 40199394
Change-Id: I58607ffdd31b319b93f5bbb1bf79e979b880fc3d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5770893
Reviewed-by: Traian Captan <tcaptan@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1339274}
--
wpt-commits: 21630ac9632a74707cfb1c4b52e826e4c95c2068
wpt-pr: 47522
Automatic update from web-platform-tests
[reading-flow] fix out of flow position reading traversal
Out of flow position elements (position: absolute, position: fixed)
are removed from normal document flow and are not included in
ReadingOrderElements. We make sure these elements still get visited
in a reading flow navigation by adding them after the
ReadingOrderelements, in DOM order.
This is similar to how we currently handle display: contents.
AX-Relnotes: No AXObject change needed, we only need to add a test.
Change-Id: Iac3d88d78542f516cf3d1834e126661a75af645b
Bug: 40932006
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5770690
Commit-Queue: Di Zhang <dizhangg@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Reviewed-by: Mark Schillaci <mschillaci@google.com>
Auto-Submit: Di Zhang <dizhangg@chromium.org>
Commit-Queue: Mark Schillaci <mschillaci@google.com>
Cr-Commit-Position: refs/heads/main@{#1339217}
--
wpt-commits: 68b127fe66b44afcef3f5f86e6e0920d2a969d1f
wpt-pr: 47530
Automatic update from web-platform-tests
[layout] Fix content-contributions of calc-size().
Previously we'd just treat calc-size() as effectively the same as auto.
This was incorrect. Instead:
- Attempt to resolve the main length, if this succeeds this is our
contribution. (This will capture the calc-size(min-content, size)
case.
- If this returns an indefinite size, we force the sizing keyword
as auto, and for the min-size treat auto as min-content, and for
the max-size treat auto as max-content.
This patch also fixes some "depends_on_block_constraints" logic
(accidentally) in cases like:
<div style="min-width: min-content; width: 0px;"></div>
where we weren't properly calculating this value.
Bug: 40339056
Change-Id: I22ee162deb49c37b948e5a22a12218b392710603
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5750362
Reviewed-by: David Baron <dbaron@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Auto-Submit: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1339188}
--
wpt-commits: 1cc5375b160d6169d8c40748bc0f05f86f791da2
wpt-pr: 47528
Automatic update from web-platform-tests
Remove the 1-argument form of calc-size().
This removes the 1-argument form of calc-size() as resolved in
https://github.com/w3c/csswg-drafts/issues/10478
Bug: 313072
Fixed: 358160890
Change-Id: I323127d93c846ee7d5a05dc06eb7f164df63ac26
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5773233
Reviewed-by: Daniil Sakhapov <sakhapov@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1339169}
--
wpt-commits: 61863a755b401efefdf0ada5ee776cd47a958357
wpt-pr: 47527
Automatic update from web-platform-tests
Add a WPT test validating that reset after flush discards frame content
There was already a test validating that reset clears the frame buffer
(2d.reset.basic), but that test called reset right after the draw
command, in the same frame. Implementation might behave differently if
a frame is actually rasterized before reset is called.
In particular, Chromium has an optimization that discards pending paint
ops when reset is called. Thus, in the original test, the frame buffer
was never actually written to before the reset and the test could not
verify whether reset actually clears that buffer. By forcing frame to
be rasterized, we now validate that the frame buffer is correctly
cleared.
Bug: 354124879
Change-Id: Ia6536568e2666138ffa4a22418a7c4eb14983577
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5746932
Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org>
Reviewed-by: Yi Xu <yiyix@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1339041}
--
wpt-commits: c9802fd711ad8316b9daf110131fbc6abc647f98
wpt-pr: 47449
Automatic update from web-platform-tests
WebNN: Define `MLContext::destroy` interface
This CL defines `MLContext::destroy` interface on blink side. It's
to destroy the `MLContext` explicitly to let it be lost.
`MLContext` retains weak references to all of the `MLBuffer`,
`MLGraph` and `MLGraphBuilder` instances, their Mojo pipes will be
disconnected and their pending promises will be rejected at the
same time as the `MLContext` is destroyed. Any calls rely on the
`MLContext` are not allowed and will throw errors.
This CL sets disconnection handler for `MLGraphBuilder` to reject
pending promise of creating `MLGraph`.
This CL removes the unnecessary `MLContext::CreateWebNNBuffer`
method, refactors `MLBuffer::ReadBufferImpl` method to create
the resolver inside and return the promise, refactors
`MLContext::CreateWebNNGraphBuilder` to record the created
`MLGraphBuilder` into `MLContext` and return it.
Bug: 348904836, 354025380
Change-Id: Ia660fe2f109a089187237da9d6a0285247f19eb9
Cq-Include-Trybots: luci.chromium.try:win11-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5737474
Commit-Queue: Mingming1 Xu <mingming1.xu@intel.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: ningxin hu <ningxin.hu@intel.com>
Reviewed-by: Rafael Cintron <rafael.cintron@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1338851}
--
wpt-commits: 2d8dac31b619e8941e383a5a68d6dfedd65b2d0b
wpt-pr: 47520
Automatic update from web-platform-tests
[Selection API] Change getComposedRanges() from rest parameter to a dictionary
Per https://github.com/w3c/selection-api/issues/176, we should update
selection.getComposedRanges() from using a rest `shadowRoots` parameter
to using a dictionary that contains the array `shadowRoots`.
Change-Id: I6b5b3fed786cf6d75fa4a20c0b2a583635cd2aca
Bug: 40286116
Fixed: 355577223
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5770701
Commit-Queue: Di Zhang <dizhangg@chromium.org>
Reviewed-by: Siye Liu <siliu@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1338832}
--
wpt-commits: 57e20404dde0cc210bbedfaf1955bad34decb16b
wpt-pr: 47523
Automatic update from web-platform-tests
Scheduling APIs: Remove scheduler.yield() parameters
By default, scheduler.yield() continuations inherit the priority and
abort signal from the current task, but this behavior can be overridden
by providing a signal or priority option. But it's not clear if this is
necessary, and there are questions around the expectations of subsequent
continuations (see https://github.com/WICG/scheduling-apis/issues/96).
So to simplify the API and prevent shipping behavior we might regret,
we're removing the yield() parameters. If control over a continuation's
priority/abort is needed, a new task can be scheduled using postTask().
We plan to reevaluate this as the API rolls out and developers start
using it in more complex ways.
Related PR: https://github.com/WICG/scheduling-apis/pull/100.
Bug: 40633887
Change-Id: I5e23c9c8cf950cec795cddafd27c962b71eea5f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5753325
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Reviewed-by: Michal Mocny <mmocny@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1338805}
--
wpt-commits: edcaaa246cdce621e114ef5bb963296457521bab
wpt-pr: 47481
Automatic update from web-platform-tests
Do not wait for events to be dispatched to IDBRequest (#47517)
The test expects event to be dispatched to IDBRequest after its execution
context is stopped, but this is not standard behavior. WebKit and Blink can stop
dispatching event as soon as iframe is detached (iframe.remove() is invoked),
which leads to test timeout. Since the goal of the test is to verify the accessor
is still valid after execution context is destroyed (no exception is thrown), we
can just check readyState without wait. We only check the type instead of value
as different engines handle the destruction differently, so the state may not be
updated right away.
--
wpt-commits: fee8ca2d5f4462af5f1dd2cb31b4e38c7256f410
wpt-pr: 47517
Automatic update from web-platform-tests
Add name from content tests for CSS text-transform (#46527)
* Add name from content tests for CSS text-transform after discussion with ARIA WG
---------
Co-authored-by: James Craig <cookiecrook@users.noreply.github.com>
--
wpt-commits: 881381e17ef3a8a8cc0390e760759a7b52b062a2
wpt-pr: 46527
Automatic update from web-platform-tests
Fix erroneous stash access in Attribution Reporting WPT server
The stash is a property of the server attribute, not the request.
Bug: 357924626
Change-Id: I57e8a6cc46a140218f410eb946894431f30d6aba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5770491
Reviewed-by: Weizhong Xia <weizhong@google.com>
Auto-Submit: Andrew Paseltiner <apaseltiner@chromium.org>
Commit-Queue: Weizhong Xia <weizhong@google.com>
Commit-Queue: Andrew Paseltiner <apaseltiner@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1338581}
--
wpt-commits: cec778a993796c6c494384662104b98944ee6fc8
wpt-pr: 47514
Automatic update from web-platform-tests
Add second WPT for notifyEvent() called with a cached event.
This variant tests that a cached click event cannot be used by
notifyEvent() after it finishes dispatching, even if notifyEvent()
has never been called on the event before.
Change-Id: If27f5bb331d5d671a81a1aa35abbdc024507b358
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5769971
Reviewed-by: Liam Brady <lbrady@google.com>
Commit-Queue: Andrew Verge <averge@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1338542}
--
wpt-commits: 065013808000fc07966a83083a12847df880e7aa
wpt-pr: 47512
Automatic update from web-platform-tests
Map transition-behavior WPT tests to web-features
These are the only two tests specifically for transition-behavior. There
are other tests, but they are for other features like the overlay
property primarily and use transition-behavior in addition.
Change-Id: I74b74366535f0a5ef145eddd42bec90094723188
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5763478
Commit-Queue: Philip Jägenstedt <foolip@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1338416}
--
wpt-commits: 6a8ddd68149fb3f1784592efab2c6d08b621c489
wpt-pr: 47507
Automatic update from web-platform-tests
Nested view transitions: support view-transition-group: contain
Instead of just saving the nearest group for every vt-name,
save also the nearest group that has "contain".
Use that group as the default instead of null when exits.
Bug: 347947051
Change-Id: I47b54f612d8b3ccbbe631fc8f0a037fc51ad9ec1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5749070
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1338321}
--
wpt-commits: 37f3ca0a24b0babb605582ac4937bb67d01d3da4
wpt-pr: 47506
Automatic update from web-platform-tests
Nested view transitions: support view-transition-group: nearest/normal
Parse nearest/normal as keywords, and use a StyleViewTransitionGroup
struct to store the result.
Rely on a stack while capturing elements hierarchically, to
correctly resolve "view-transition-group: nearest".
Also use that stack instead of element ancestry for
computing explicit names.
Bug: 347947051
Change-Id: If06d2a6ff266013f4a46a492191c31e4a66111c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5752182
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1338320}
--
wpt-commits: 3634d5a63f2fa3969616396d95537c91c3348fe5
wpt-pr: 47505
Automatic update from web-platform-tests
[Editing] Update Selection before removing element in contenteditable
div
When an element is removed from a node, making it empty, the selection
was not updated accordingly. This resulted in the |OnSelectionChange|
event not being fired. To resolve this, the selection is now updated
prior to the removal of the element that makes the node empty.
Consequently, the |OnSelectionChange| event is fired through frame
selection.
Bug: 40876506
Change-Id: I2181ce44eb1356377c658bd6ba91023508ee4939
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5694338
Reviewed-by: Siye Liu <siliu@microsoft.com>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Tanu Jain <tanujain@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1338306}
--
wpt-commits: a1d1cdb6a171cd187162329cdce7ddd45bec93d1
wpt-pr: 47504
Automatic update from web-platform-tests
Nested view transition: reparent & render
This tracks the view-transition-group for the captured elements
as "containing group". Those values are filtered to only include
ancestors.
* When a captured element has a valid containing group, the
pseudo-element is reparented to the containing group when the
view transition starts.
* Note that when capturing the old element, we don't deal with nesting
at all. The tree for the purpose of allowing the compositor to
capture the old state is flat. This can be revisited iteratively,
it's done for implementation simplicity.
* When building styles, the (inverse) parent transform is adjusted
so that it's not applied twice.
* Changed all the recursive functions to retrieve pseudo-elements
to adapt to nested containers.
Currently, by default mismatches here are handled by
"last capture wins", however this is to be resolved in the CSSWG so it's not tested yet: https://github.com/w3c/csswg-drafts/issues/10631
Note also that with the current implementation, after capturing the
old state and before starting might appear broken, as
clipping/opacity/etc are not applied to the generated pseudo-element.
Bug: 347947051
Change-Id: I49e4f7ea6c8d82b6ad34b50f8cda92eb3f074612
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5749090
Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1338296}
--
wpt-commits: c0b10b3c6286687496b07265dfca91eb5923cc79
wpt-pr: 47494