Automatic update from web-platform-tests
Radio buttons should make a group even if they are disconnected and not owned by a form
If a radio button is connected or owned by a form, radio button
groups are managed by RadioButtonGroupScope in order to complete
various operations for a group in O(1).
Otherwise, we did not assume a radio button belonged to any
groups. It didn't conform to the HTML standard, and was not
interoperable with Firefox.
After this CL, such radio buttons are grouped without
RadioButtonGroupScope's help. We iterate over the tree including
the target radio buttons to find a checked button in the group or
|required| attribute in the group.
Bug: 883723
Change-Id: I56185559592dff6b0254655aeb499ed6ac29df64
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1988087
Commit-Queue: Kent Tamura <tkent@chromium.org>
Reviewed-by: Mason Freed <masonfreed@chromium.org>
Cr-Commit-Position: refs/heads/master@{#729577}
--
wpt-commits: c171dad65cd054f73ebf92133e477ffdaa38c3a1
wpt-pr: 21059
Automatic update from web-platform-tests
Apply CSP to 'DOMParser.parseFromString' documents.
This applies the CSP of the context document to any doc created by calling
DOMParser.parseFromString. The original implementation, as it returned a
pointer to the CSP instance of the context document, which (in some
circumstances) could mean that the CSP of the context document itself was
modified. This makes a copy of the context document's CSP, before assigning it
to the newly created document.
This re-reverts / re-lands
1975710: Revert CSP application to `DOMParser.parseFromString`.
1917532: [Trusted Types] Fix Trusted Types for other document types
Bug: 1030830, 951536
Change-Id: I33adff8c376a6f37788c9aee0ef7ca0c3441785f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1980183
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#729496}
--
wpt-commits: 0b654aa23ecd6e2f7483bbd6be01bf3c705a4a44
wpt-pr: 21020
Automatic update from web-platform-tests
Port css-transform related composition tests to external
Chrome passes all and
firefox failed the translate-composition due to expect 'None' and got '0px'
Bug Filed:https://bugzilla.mozilla.org/show_bug.cgi?id=1607313
Bug: 1034538
Change-Id: I1700cae51d539ea0d76ebe73efbaa6e038d6f5fb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1982776
Reviewed-by: Xida Chen <xidachen@chromium.org>
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#729453}
--
wpt-commits: 2131c310151ff4b76d9b69a8e3b2106b1dd66431
wpt-pr: 21000
Automatic update from web-platform-tests
Port css-flexbox related composition to external
Both Chrome and Firefox pass the test
Bug: 1034538
Change-Id: I3e43cf22a1ed9ce8d4d10aca5250dcbf243ebb84
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1985813
Reviewed-by: Xida Chen <xidachen@chromium.org>
Commit-Queue: Hao Sheng <haozhes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#729438}
--
wpt-commits: 3ebfc1155760fc0be7cb75abe85c03ecddd30368
wpt-pr: 21001
Automatic update from web-platform-tests
Reject cookies with empty names and values.
As discussed in [1], cookies with empty names and empty values should be
rejected. This patch removes the carveout made in https://crbug.com/601786,
and adjusts unittests accordingly.
This patch does not change the WPT expectations; we'll do that at the same
time we change the spec. In the meantime, we'll check in local expectations
matching the behavior we believe is correct.
[1]: https://github.com/httpwg/http-extensions/issues/159#issuecomment-569233866
Bug: 1037996, 601786
Change-Id: I53319cee385efff019b313479184236c53b1d783
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1982549
Reviewed-by: Lily Chen <chlily@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#729403}
--
wpt-commits: 3adc15d3ba2e20e9ae79daf019cb784934f0fa7f
wpt-pr: 20923
Automatic update from web-platform-tests
Temporarily disable allowed-to-play.html test in Firefox
This is causing timeouts in unrelated infra PRs. The bug is tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1607802 and the test
should be reenabled once that bug is fixed.
--
wpt-commits: 0d874bb07e639c521b044164e80b5df2aada5aeb
wpt-pr: 21088
Automatic update from web-platform-tests
[css-scroll-snap] Allow style changes to invalidate snap data
All snap container data was only updated and re-snapped after layout
changes. However, this invalidation needs to sometimes happen after
style changes too (such as changing 'scroll-snap-align').
Now, PaintLayerScrollableArea has flags for indicating that it needs
to update its snap container data, which are set during certain style
changes and layout changes. Then all snap container data that has the
flag set will be updated, and attempt to re-snap if any data changes.
This also prevents us from updating snap containers that haven't
changed.
The follow-up for this is to invalidate snap containers when changing
the transform property of their content.
Bug: 984794,1028316
Change-Id: I432500df98fdbe63e3b7eed3ba43e05465f9d873
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1962567
Commit-Queue: Yi Gu <yigu@chromium.org>
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Reviewed-by: Yi Gu <yigu@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#729345}
--
wpt-commits: 09a5ffbe707cfae350728188527f6fe8cabc884d
wpt-pr: 20751
Automatic update from web-platform-tests
CacheStorage: Set opaque mode for code cache.
This CL restores code to set the V8 code cache generation opaque mode
based on the response tainting. It was previously incorrectly removed
in crrev.com/c/1828726.
This CL adds a test that verifies scripts loaded from cache_storage are
treated as opaque when appropriate. It has been verified to fail
without the fixed code.
The CL also fixes an incorrect DCHECK that the test triggers. The
assumption in the DCHECK was incorrect and should instead be a runtime
check.
Bug: 1037701
Change-Id: I894b30ad9dac6c3a47e1b5f325ee7906768b57f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1988675
Commit-Queue: Ben Kelly <wanderview@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#729327}
--
wpt-commits: 81c0fbb492fae66728077460e69b3161415bd24a
wpt-pr: 21074
Automatic update from web-platform-tests
[webnfc] Provide more detailed error message (#21016)
Previously, when some errors happened in Device Service for
pushing/watching, an enum error type is passed to Blink. Based on this
enum Blink will 1) select a DOMExceptionCode and 2) create an
appropriate error message, then construct a DOMException to expose to JS.
However, usually the error message created above by Blink is just a
generic message that cannot express any detailed information about
how/why the error happened.
This CL switches to let Device Service (the exact place errors happened)
generate the error message with more helpful information and pass it
together with the enum error type to Blink.
BUG=995210
Change-Id: I37cff489d3d68337527e5db3681088e8f9e94213
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1986625
Commit-Queue: Leon Han <leon.han@intel.com>
Reviewed-by: François Beaufort <beaufort.francois@gmail.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#729257}
Co-authored-by: Han Leon <leon.han@intel.com>
--
wpt-commits: 6777a42cfed14960ffb7bb20c01c091857652ba9
wpt-pr: 21016
Automatic update from web-platform-tests
[webnfc] NDEFScanOptions#mediaType being undefined means do not filter (#21017)
And the empty string should just match on empty.
The spec change:
https://github.com/w3c/web-nfc/pull/496https://github.com/w3c/web-nfc/pull/498
BUG=520391
Change-Id: Idae55b976a6fbbdd252f6227cbe13ee50d16269c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1986632
Reviewed-by: Rijubrata Bhaumik <rijubrata.bhaumik@intel.com>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Leon Han <leon.han@intel.com>
Cr-Commit-Position: refs/heads/master@{#728813}
Co-authored-by: Han Leon <leon.han@intel.com>
--
wpt-commits: 32cb1cf1ba99807715ab5a4184f62e39c47d18f7
wpt-pr: 21017
Automatic update from web-platform-tests
[html] Update COOP tests
The possible values of the `Cross-Origin-Opener-Policy` header have
changed since these tests were authored:
- `same-origin unsafe-allow-outgoing` is now `same-origin-allow-popups`
- `same-site` and `same-site unsafe-allow-outgoing` have been removed
and no equivalent value is available
- `unsafe-inherit` is now `unsafe-none`
Reflect these changes in the relevant tests. Introduce cases for the
removed values to ensure that they are no longer honored.
Additional stability fixes:
- Mark more tests as long timeout.
- Split up some tests that were taking too long to run.
- Remove one use of step_timeout and tweak 2 other instances.
Co-authored-by: Simon Pieters <zcorpan@gmail.com>
--
wpt-commits: a1e7a4e87e0c752caff7321636a599e56b4be13c
wpt-pr: 20874
--HG--
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-origin-unsafe-allow-outgoing.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/historical/popup-same-origin-unsafe-allow-outgoing-with-cross-origin.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/coop-navigated-popup.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/historical/popup-same-origin-unsafe-allow-outgoing-with-same-origin.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/coop-navigated-popup.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/historical/popup-same-origin-unsafe-allow-outgoing-with-same-site.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-site-unsafe-allow-outgoing.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/historical/popup-same-site-unsafe-allow-outgoing-with-cross-origin.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-site-unsafe-allow-outgoing.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/historical/popup-same-site-unsafe-allow-outgoing-with-same-origin.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-site-unsafe-allow-outgoing.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/historical/popup-same-site-unsafe-allow-outgoing-with-same-site.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-site.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/historical/popup-same-site-with-cross-origin.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-site.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/historical/popup-same-site-with-same-origin.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-site.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/historical/popup-same-site-with-same-site.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-origin.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/popup-meta-http-equiv.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-origin.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-origin-with-cross-origin.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-origin.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-origin-with-same-origin.https.html.headers
rename : testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-origin.https.html.headers => testing/web-platform/tests/html/cross-origin-opener-policy/popup-same-origin-with-same-site.https.html.headers
Automatic update from web-platform-tests
Add a WindowProxy definition to html/dom/idlharness.worker.js
--
wpt-commits: 638a14f5d9cc2c550cd80c409b47ba088f485039
wpt-pr: 21079
Automatic update from web-platform-tests
Fix style section to return text/css (#21069)
Since this is being referenced by link elements, the content type
should be text/css and also a stylesheet should be returned rather
than html.
--
wpt-commits: 05d01eb71d168d1f1e4c8edc16e62cf0c1548e92
wpt-pr: 21069
The error message isn't really explicit, but wrapping the call
to toggleBrowserConsole in a try/catch block seems to remove
the test failure.
Differential Revision: https://phabricator.services.mozilla.com/D59657
--HG--
extra : moz-landing-system : lando
Glean init does some I/O which is forbidden on the main thread (especially
during startup). Though not recommended for mobile platforms, let's init it
off the main thread.
Later versions of the Glean SDK might take care of off-thread I/O during init.
But for now, let's do it ourselves.
Depends on D59532
Differential Revision: https://phabricator.services.mozilla.com/D59760
--HG--
extra : moz-landing-system : lando
The end of the std::thread at process end didn't seem to release the owned
nsStringBuffer in a way that refcounting liked. So let's copy the nsAString
into an owned String, move it into the thread's closure, and convert it as
necessary to an nsAString when we invoke pingsender.
Not the most efficient, but it doesn't have to be. This is prototype code
that will be removed.
Differential Revision: https://phabricator.services.mozilla.com/D59531
--HG--
extra : moz-landing-system : lando
nsIProcess is the tried-and-true method for launching utility subprocesses on
Firefox Desktop's supported platforms. Use that.
Differential Revision: https://phabricator.services.mozilla.com/D58809
--HG--
extra : moz-landing-system : lando
Since we're the only one sending data, and we're doing so infrequently, let's
get the pref value before each ping send instead of building a pref observer
right this second.
Differential Revision: https://phabricator.services.mozilla.com/D57107
--HG--
extra : moz-landing-system : lando
ContentBlockingEvents is now accessed via WindowGlobalActor::ContentBlockingEvents.
Updating and storing contentBlockingEvent in RemoteSecurityUI are no longer needed.
Depends on D55622
Differential Revision: https://phabricator.services.mozilla.com/D55623
--HG--
extra : moz-landing-system : lando
ContentBlockingEvent in RemoteSecurityUI is updated after receiving a notification from a child process.
Since contentBlockingEvent will be removed from the child, this patch removes the use of
contentBlockingEvent in RemoteSecurityUI and uses the API defined in WindowGlobalActor.
Depends on D55621
Differential Revision: https://phabricator.services.mozilla.com/D55622
--HG--
extra : moz-landing-system : lando
This allows us to access contentBlockingEvents in the parent process
through a WindowGlobalParent object.
Differential Revision: https://phabricator.services.mozilla.com/D55621
--HG--
extra : moz-landing-system : lando
Teach `mach browsertime` to tell you to `mach browsertime --setup` if we're not already set up
Differential Revision: https://phabricator.services.mozilla.com/D59501
--HG--
extra : moz-landing-system : lando
Let's stop if the packages could not be installed.
Also, let's skip the call if we find them.
Differential Revision: https://phabricator.services.mozilla.com/D59690
--HG--
extra : moz-landing-system : lando
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
If `TextControlState` does not have `TextEditor` and its `SetValue()` is called
from `SetUserInput()`, `TextControlState` itself needs to dispatch `beforeinput`
event.
If the value is modified by `beforeinput` event listener, it's intended that
`preventDefault()` is called by the web apps. However, the behavior in this
case is not mentioned by UI Events nor Input Events spec. We should just file
a spec issue instead of emulating Chrome's behavior for now because it requires
more changes, but this case must be an edge case.
The spec issue is: https://github.com/w3c/input-events/issues/106
Differential Revision: https://phabricator.services.mozilla.com/D58126
--HG--
extra : moz-landing-system : lando
