[pull] master from web-platform-tests:master #2809
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Depending on whether the .test-case style was parsed in time for the first style calculation we can get 1 or 3 transitions starting. Fix by ensure a style update ahead of setting the transition property. Bug: 381132303 Change-Id: If13c2a13cb93d4b6452aa2ed55551e0f782b4c1f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6064022 Commit-Queue: Kevin Ellis <kevers@chromium.org> Reviewed-by: Robert Flack <flackr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392402}
Co-authored-by: wpt-pr-bot <wpt-pr-bot@users.noreply.github.com>
….html doesn't run in WebKit (#49553) Pass the content type when constructing the Blob so that it is guaranteed to be rendered inside the iframe. Without specifying the content type, Gecko was treating treating the blob as HTML, Blink was treating it as text and WebKit was treating it as binary and downloading it instead of rendering it inside the iframe.
https://html.spec.whatwg.org/#inert-subtrees doesn't have anything about stuff behaving as disabled. I think we should remove -moz-user-input too, but that is probably worth doing separately. Differential Revision: https://phabricator.services.mozilla.com/D231116 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1926304 gecko-commit: 4c30676d268fa2239cd143fd4b6d212ebcb0c91e gecko-reviewers: smaug
These are ~covered by unit tests, but adding WPT provides an end-to-end check of the integration between the components. Bug: 380783670 Change-Id: I12dc2c66245648d98f35cce64abf36ab7298b919 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6068733 Reviewed-by: Camille Lamy <clamy@chromium.org> Commit-Queue: Mike West <mkwst@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392527}
Differential Revision: https://phabricator.services.mozilla.com/D230532 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1929461 gecko-commit: f0cdd7fd077b3d3ca224aace40fd2d40a5027d0e gecko-reviewers: gfx-reviewers, nical
We were sizing absolutely positioned replaced elements within their actual containing block instead of the inset-modified containing block. Then the `stretch` keyword would result in a wrong size. Signed-off-by: Oriol Brufau <obrufau@igalia.com>
For the API, please see https://www.w3.org/TR/wasm-js-api-2/#memories https://webassembly.github.io/threads/js-api/index.html#memories Bug: 42202693 Change-Id: Ifddbb3677d1ce8fcb9e3d5fd5b65408613e228f0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6072248 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392535}
This adds WebDXFeature and WPT test mapping for VerticalFormControls. The WebDX feature entry can be found at: https://web-platform-dx.github.io/web-features-explorer/features/vertical-form-controls/ Change-Id: I0bb16dbeb83cdf439e6f7785fe7b48e0b38c31aa Bug: 40086540 Bug: 366475997 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6071504 Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Di Zhang <dizhangg@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392695}
Fixes crash error when html element with ::first-line style has only one line. Bug: 382322945 Change-Id: Id87d7b5b19f7229faba4f6705c3794781af83f08 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6072686 Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Sambamurthy Bandaru <sambamurthy.bandaru@microsoft.com> Reviewed-by: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1392718}
In delete_selection_command.cc, |MakeStylingElementsDirectChildrenOfEditableRootToPreventStyleLoss| calls |CreateRange| on selection to delete. Then the result range is directly used without a null check to get the |FirstNode|. This causes an exception which has been fixed by introducing a null check before accessing. Bug: 373971769 Change-Id: I7c0a68ba8dc2a99a143aa5edd13686174cd7839a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6048561 Reviewed-by: Ashish Kumar <ashishkum@microsoft.com> Commit-Queue: Pranav Modi <pranavmodi@microsoft.com> Reviewed-by: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392725}
Element-insertAdjacentText is a duplicate of Element-insertAdjacentHTML (and is named incorrectly)
Previously, the `mojom::TranslationManager` interface was only accessible from frames because it was registered with the mojo binder map only within the `PopulateChromeFrameBinders` method. This CL makes the `mojom::TranslationManager` interface available to workers by introducing a new public method in `ContentBrowserClient` `BindTranslationManager()`. This method is called by the following methods: - `PopulateFrameBinders()` - `PopulateDedicatedWorkerBinders()` - `PopulateSharedWorkerBinders()` - `PopulateServiceWorkerBinders()` Additionally, this CL updates the relevant IDL files to expose the Translator API to workers. Fixed: 381983087 Change-Id: Ib14ef9137340054f05fac4b67dd29ae928b64bfc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6069226 Commit-Queue: Tsuyoshi Horo <horo@chromium.org> Reviewed-by: Rakina Zata Amni <rakina@chromium.org> Reviewed-by: Fergal Daly <fergal@chromium.org> Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392829}
Implement hash reporting for scripts as part of CSP. PR: w3c/webappsec-csp#693 Change-Id: Ie8d97d6094ca7601d84258cc5e1bca540eb49b39 Bug: 377830102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6038298 Reviewed-by: Antonio Sartori <antoniosartori@chromium.org> Commit-Queue: Yoav Weiss (@Shopify) <yoavweiss@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392854}
...P.Agg. already has some (as wpt_internal), but this focuses on FLEDGE-specific functionality while trying not to worry about the Private Aggregation details. (More follow up tests expected for newly added metrics as well as reserved.once in component auctions). Bug: 361262468 Change-Id: Ie51bc98d2f9e05d8709a9189d1d8aa49218c301b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6049298 Reviewed-by: Russ Hamilton <behamilton@google.com> Commit-Queue: Maks Orlovich <morlovich@chromium.org> Reviewed-by: Alex Turner <alexmt@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392885}
Add more kinds of leading/trailing whitespace subtests to verify the effects on actualBoundingBoxLeft/actualBoundingBoxRight text metrics.
This was already unintentionally supported due to the handling of the attributionsrc attribute on HTMLAnchorBaseElement, and is reasonable to support anyway, as <area> is a first-class navigation surface, just like the already supported <a> and window.open. WICG/attribution-reporting-api#1465 I2S: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/673f72a6.2b0a0220.3bb1d2.02f2.GAE%40google.com Bug: 369219144, 379275911 Change-Id: I7230229de087c752af7a5be2f7663fff999d66e0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6022268 Reviewed-by: Nate Chapin <japhet@chromium.org> Reviewed-by: Domenic Denicola <domenic@chromium.org> Commit-Queue: Andrew Paseltiner <apaseltiner@chromium.org> Reviewed-by: John Delaney <johnidel@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392912}
for the new ::checkmark and ::picker-icon pseudo elements Bug: 382291440 Change-Id: Ie8d2f34a64b9c733dd863e53328ca4ec3a34347a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6075944 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Traian Captan <tcaptan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1392977}
Change-Id: If037e8b23ce84ab7fe040227b4ae178d677148d8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6072689 Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Auto-Submit: Traian Captan <tcaptan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1393021}
Change-Id: Ie41a6ea04993f91d5cdbdad15b25a770aeb2e6ad Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6071442 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1393056}
Bug: 361262468 Change-Id: I33c2437d4ba2e519ed85848ef14f82867cc9b751 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6064245 Commit-Queue: Maks Orlovich <morlovich@chromium.org> Reviewed-by: Russ Hamilton <behamilton@google.com> Cr-Commit-Position: refs/heads/main@{#1393091}
This covers average-code-fetch-time and behavior of reserved.once in component auctions. Bug: 361262468 Change-Id: I542cb819ed38b5931fa863f3695b918b4b7fe4df Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6077370 Reviewed-by: Russ Hamilton <behamilton@google.com> Commit-Queue: Maks Orlovich <morlovich@chromium.org> Cr-Commit-Position: refs/heads/main@{#1393108}
lstm requires weights and bias to be constants and they have different shapes compared to webnn spec. So the weight serialization needs to be changed to be done lazily. For all weights and biases, if it's bidirectional, they are splitted to two weights(with extra transposes and reshapes). Additionally bias and recurrent_bias are combined to a single bias param. Change-Id: I5881ff4a0618e5a9584d39099faa6ac30f4570e7 Bug: 360052663 Cq-Include-Trybots: luci.chromium.try:mac14.arm64-blink-rel,mac15-blink-rel,mac15.arm64-blink-rel Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6071582 Reviewed-by: Austin Sullivan <asully@chromium.org> Commit-Queue: Phillis Tang <phillis@chromium.org> Cr-Commit-Position: refs/heads/main@{#1393164}
This was resolved here: w3c/csswg-drafts#11039 (comment) Change-Id: Icfe2bbf5a7b87c50a52cedae98021425a5121429 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6049400 Reviewed-by: Tommy Nyquist <nyquist@chromium.org> Auto-Submit: Joey Arhar <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1393165}
The options dictionary was removed from the layer spec pull request. https://crrev.com/c/5904350 made all the generated test validating that feature tentative, but the manual tests were left untouched. This CL removes the layer parameter from these tests. That parameter used to be relevant back when unclosed layers could be presented, but now, layers never gets rendered until they are closed, which makes the filter parameter in these tests irrelevant. Bug: 40249439 Change-Id: I70dbc001e596ce70db6b70b059be2829644c0b24 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6069956 Reviewed-by: Yi Xu <yiyix@chromium.org> Commit-Queue: Jean-Philippe Gravel <jpgravel@chromium.org> Cr-Commit-Position: refs/heads/main@{#1393198}
https://web-platform-dx.github.io/web-features-explorer/features/closewatcher/ Change-Id: I83f2556cee77fa4cf9e8277af1628ce5864b5096 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6072053 Reviewed-by: Di Zhang <dizhangg@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1393211}
This fixes a type error, some missing includes, and a measurement issue where the check of the measured framerate is too strict, as described inline. Also adds some styling fixes. Differential Revision: https://phabricator.services.mozilla.com/D231233 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1920530 gecko-commit: 828c2a51cf69630ecb4a7c422b60691315e80380 gecko-reviewers: jib, bwc
…about sign() with mixed lengths. Closes web-platform-tests/interop#911
The CSS working group resolved[1] that when a scroll operation is aimed at an element, i.e. Element.scrollIntoView, the associated scroll-marker-group should select the active scroll-marker based on the element which the operation is intending to scroll to. In such cases, the scroll-marker that should be selected is the scroll-marker associated with the first scroll target (a scroll target is an element which generates a scroll-marker) found through a search starting from the target of the scrollIntoView itself and backwards in tree-order. As soon as some other type of scroll occurs, e.g. Element.scrollTo, or a user gesture scroll, the scroll-marker-group should no longer consider its active marker pinned, i.e. it should be based on the scroll position. This patch implements this for elements in general, but not for ::column pseudo elements which may also act as scroll targets since ::column::scroll-marker is allowed. The ::column case needs to be handled specially as ::column pseudos are not parents of the elements which are flowed into them in the DOM tree. This will be done in a follow-up patch. [1] w3c/csswg-drafts#10738 (comment) Bug: 380062280 Change-Id: I363e0f055f9791ead0b35f4bbe037db91f299624 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6089232 Reviewed-by: Steve Kobes <skobes@chromium.org> Commit-Queue: David Awogbemila <awogbemila@chromium.org> Cr-Commit-Position: refs/heads/main@{#1399197}
::column pseudos[1] may create ::scroll-markers, but do not exist in the DOM tree as parents of the elements which are flowed into them. They also do not appear to have LayoutObjects and are not found[2] in the layout tree. So, when searching for the appropriate scroll-marker to select for a targeted scroll we need to consider whether the scroll-marker-generating element (marker-generating-element) found in the layout tree is also flowed into the same scroll-marker-generating ::column (marker-generating-column) as the target of the scrollIntoView operation. If the target and marker-generating-element are both in marker-generating-column, marker-generating-element is the preferred[3] choice. The only means we have of checking whether an element is flowed into a ::column is by looking at the rect associated with that ::column. [1] https://drafts.csswg.org/css-multicol-2/#column-pseudo [2] https://source.chromium.org/chromium/chromium/src/+/165f5ddad25b289f886a248ca810d075b1e7bb87:third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc;l=254-255 [3] w3c/csswg-drafts#10738 (comment) Bug: 380062280 Change-Id: Ie2ad58c3beca13a4945325d9aa9c4aec6a5fc332 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6088285 Commit-Queue: David Awogbemila <awogbemila@chromium.org> Reviewed-by: Steve Kobes <skobes@chromium.org> Cr-Commit-Position: refs/heads/main@{#1399198}
The spec states that non-image feImage references should be rendered "according to the behavior of the use element" (https://drafts.fxtf.org/filter-effects/#feImageElement), which is nothing for the case of a standalone tspan. Fixed: 383187487 Change-Id: If3f8438676c593f6e9aab4f879ea9212a0806621 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6111507 Reviewed-by: Fredrik Söderquist <fs@opera.com> Commit-Queue: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1399218}
… even after mutations by web apps Gmail composer puts non-editable `<span>` to show a suggestion to make autocomplete feature available. Then, if user types a white-space, Gmail composer replaces or deletes the non-editable `<span>`. When user types a white-space before the non-editable `<span>`, our editor does not think that `<br>` is required to make the white-space visible because of the following non-editable text. However, it'll be removed asynchronously. Then, the white-space becomes invisible trailing white-space of the block and `Selection` is collapsed after it. Therefore, following editing behaves odd because our editor does not handle correctly editing in invisible white-spaces. As you know, Gecko is the only browser to use the ASCII space (U+0020) as a trailing collapsible white-space immediately before a block boundary. Therefore, web apps may implement this feature with similar approach without taking care of Gecko. Therefore, we should use a hack for our uses. Fortunately, this may occurs only when user appends a collapsible white-space to end of a `Text` node. Therefore, `HTMLEditor` can cache the last `Text` node whose last character is recently appended collapsible white-space. Then, when our mutation observer detects that the white-space becomes invisible, the mutation observer can put a padding `<br>` element. Unfortunately, the `<br>` is put with the transaction. Therefore, undoing it deletes only the padding `<br>` and does not delete the white-space. However, it's hard to touch transaction management right now. Therefore, this patch does not fix this issue. Differential Revision: https://phabricator.services.mozilla.com/D232599 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1938110 gecko-commit: ec81b9013110d43c3d8e32ca1842422497530c29 gecko-reviewers: m_kato
* Regularly add core WebAssembly tests to WPT * Fix Wasm spelling * Address review feedback - Add myself as a reviewer for .github/ - Remove the path fix up step as it's now done by build.py - Use better name for the wpt repo directory
Since we are only planning to support one <selectedcontent> element in <select>, this patch only performs a clone into the first <selectedcontent> in tree order. This is in response to feedback here: whatwg/html#10633 (comment) This patch also removes the logic which clears <selectedcontent> elements when they are removed/disconnected. Change-Id: I1580ec9f12df463d1f5134905e3e527cfefa694d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6043186 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1399301}
See whatwg/dom#1307 (comment). R=nrosenthal@chromium.org Bug: 40150299 Change-Id: I9529941e05591620da5b3c11635693a15f0ce866 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6111212 Reviewed-by: Noam Rosenthal <nrosenthal@chromium.org> Commit-Queue: Dominic Farolino <dom@chromium.org> Cr-Commit-Position: refs/heads/main@{#1399350}
* Update Wasm tests * Ignore linting errors in automatically imported Wasm tests --------- Co-authored-by: wpt-pr-bot <wpt-pr-bot@users.noreply.github.com> Co-authored-by: Panos Astithas <pastithas@google.com>
Fixes some minor bugs with CoreML bidrection implementation. Also adjusted ULP for this complex op to 3, this is same as gru. Bug: 360052663 Change-Id: Ie15ab15a359be70e219fd61ee0d3a3fea21f3405 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6103076 Commit-Queue: Phillis Tang <phillis@chromium.org> Reviewed-by: Reilly Grant <reillyg@chromium.org> Cr-Commit-Position: refs/heads/main@{#1399398}
...by making sure to always explicitly use a .test coordinator. Bug: 383600441 Change-Id: Ib163b5042ebfdb04d906c9bd549f323cbed45768 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6094505 Reviewed-by: Mason Freed <masonf@chromium.org> Reviewed-by: Russ Hamilton <behamilton@google.com> Commit-Queue: Maks Orlovich <morlovich@chromium.org> Cr-Commit-Position: refs/heads/main@{#1399474}
A block-in-inline may only contain fragmented parallel flows, for all we
know, so it cannot unconditionally count as "in-flow", since we might
fail to mark a container as potentially non-contiguous that way.
In the test included, there's a text node "x xx", where the first word
should be in the first column, and the second word should be in the
fourth. There's no room for such a wide piece of text ("xx") before
we're past the tall float.
Bug: 346876226
Change-Id: I5bcf8840a1c71783dfa0bdce442a92eb5ddbf7b4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6108448
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1399542}
In order to compute the inline min-content and max-content contributions of an anonymous block, we were finding its min-content and max-content inline size with a SizeConstraint coming from the block size of the box. However, anonymous blocks do not establish a containing block for their contents, so this patch uses a SizeConstraint from the block size of the containing block. Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Differential Revision: https://phabricator.services.mozilla.com/D232725 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1871346 gecko-commit: d13caad2c6161773f359021d3ebe132880d93bf6 gecko-reviewers: webdriver-reviewers, Sasha
As per WICG/signature-based-sri#33, the plan is to reject the `alg` parameter entirely, rather than locking it to a single value. Bug: 385160702 Change-Id: Iba57570fd8d0136b1d68e143a2fde5f48cd69806 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6110599 Reviewed-by: Kenichi Ishibashi <bashi@chromium.org> Commit-Queue: Mike West <mkwst@chromium.org> Reviewed-by: Yoav Weiss (@Shopify) <yoavweiss@chromium.org> Cr-Commit-Position: refs/heads/main@{#1399650}
…lete-before-invisible-line-break.html` to under `mozilla These tests were introduced in bug 1923251 at first landing. They are for testing the behavior when the last character before block boundary is changed because we require a padding line break if the last character is a collapsible white-space. However, Chrome uses an NBSP for the last white-space and `<br>` does not make the last collapsible white-space visible different from Gecko. Therefore, Microsoft has changed the test and changed the expected results which won't test what I'd have liked to check. In the Chrome's behavior, they are not required, but they are important to touch our text editing code. So, they should be under Mozilla specific directory. Differential Revision: https://phabricator.services.mozilla.com/D231661 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1936196 gecko-commit: 3ad01295891b44d4d569e436b2dc0341c79b6fae gecko-reviewers: m_kato
…eaks never expect preformatted linefeeds for padding line breaks In bug 1926194, I changed the tests under editing/plaintext-only as expecting only preformatted linefeeds. However, I realized that using preformatted linefeeds for paddling line breaks is wrong because they will appear in `.textContent` value even though they are invisible. Differential Revision: https://phabricator.services.mozilla.com/D231663 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1936193 gecko-commit: 789dc713f04938fd1d86f07dcdf24c3953f0f474 gecko-reviewers: m_kato
Block layout uses some heuristics to guess whether margins are separated by clearance and then don't collapse. These heuristics now take the min-content, max-content, fit-content and stretch sizing keywords into account. Signed-off-by: Oriol Brufau <obrufau@igalia.com>
This PR add a missing new line at the end of `lint.ignore`, to fix the broken CTS CI workflow which would write line to that file assuming there is a new line existed at the end of file.
This make the implementation look very close to https://w3c.github.io/paint-timing/#mark-paint-timing The render coarsening and queuing logic is all consolidated into PaintTiming::MarkPaintTimingInternal. Also previous alignment mechanisms such as the buffer in WindowPerformance and clamping to FCP are no longer needed. Bug: 381270287 Change-Id: I9ef0a1ebbc9417e2d65415712fbbb554df64d8d3 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6087964 Reviewed-by: Michal Mocny <mmocny@chromium.org> Commit-Queue: Noam Rosenthal <nrosenthal@chromium.org> Cr-Commit-Position: refs/heads/main@{#1396678} Co-authored-by: Noam Rosenthal <nrosenthal@chromium.org>
The CSP frame-ancestors checking algorithm matches the frame ancestor's origin against the source list. An origin will never match a URL with a path in the source list. Hence this CL adds a web platform test checking that frame loads are blocked if frame-ancestors includes a URL with a path. Bug: 40780874 Change-Id: I33a461a1f69b040d8a5e803978161352821d4161 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6094569 Reviewed-by: Antonio Sartori <antoniosartori@chromium.org> Commit-Queue: Emily Stark <estark@chromium.org> Cr-Commit-Position: refs/heads/main@{#1397345} Co-authored-by: Emily Stark <estark@google.com>
This tests for differences between setHTML and setHTMLUnsafe. Since the html5lib testcase format only supports one result per testcase, we use two testcase files with identical inputs, one each with the expectations for safe and unsafe variants. Also, a drive-by fix for an issue uncovered by the tests: The spec demands we block insertion in a <script> element (in safe cases). Bug: 356601280 Change-Id: I1fb19f60fdcd7262292a983b548baebcaf43a440 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6039899 Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by: Yifan Luo <lyf@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1397856} Co-authored-by: Daniel Vogelheim <vogelheim@chromium.org>
Bumps [mypy](https://github.com/python/mypy) from 1.11.0 to 1.14.0. - [Changelog](https://github.com/python/mypy/blob/master/CHANGELOG.md) - [Commits](python/mypy@v1.11...v1.14.0) --- updated-dependencies: - dependency-name: mypy dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: Domenico Rizzo <domenico.rizzo@gmail.com>
Previously, codec strings containing spaces were trimmed, and VideoDecoder would report them as "supported". However, per changes introduced in PR #48870 [1], such codec strings, while "valid" in terms of syntax, should be considered "unsupported" by the VideoDecoder. Given that codec strings with spaces should be marked as "unsupported", it's unnecessary to parse these codec strings before checking if they are supported video codecs. The underlying checking method reports codec strings containing spaces as "unsupported", naturally aligning with the expected behavior. [1] #48870 Differential Revision: https://phabricator.services.mozilla.com/D231716 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1931827 gecko-commit: 375d118ff39a50118a2fa26b3892d81da6f327a8 gecko-reviewers: media-playback-reviewers, alwu
This patch updates AudioDecoder to return "unsupported" for codec strings containing spaces, consistent with the approach taken in the preceding patch. As part of this update, the `AudioMIMECreateParam` class is removed since there is no longer a need to trim spaces from codec strings. Any codec string containing spaces is immediately considered "unsupported". Additionally, this patch adds a WPT to verify that AudioDecoder correctly returns "unsupported" for codec strings with spaces, ensuring the decoder behaves as expected. Differential Revision: https://phabricator.services.mozilla.com/D231717 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1931827 gecko-commit: b28767c670a7bb8d22744d3586b7bac7ef73d785 gecko-reviewers: media-playback-reviewers, alwu
This patch updates AudioEncoder to return "unsupported" for codec strings containing spaces, consistent with the approach taken in the preceding patch. By moving `IsSupportedAudioCodec` to `CanEncode` and removing the unnecessary codec string trimming, AudioEncoder now behaves as expected since codec string with spaces fails to pass `IsSupportedAudioCodec`'s check. A WPT is also added to verify that AudioEncoder returns "unsupported" when passing codec strings that contains spaces to `IsConfigSupported` or `configure`. Differential Revision: https://phabricator.services.mozilla.com/D231718 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1931827 gecko-commit: 709c474955599eed0ae62f9d8815b517c7d1cf07 gecko-reviewers: media-playback-reviewers, alwu
This patch fixes a crash that occurs when a codec string with leading spaces is passed to `VideoEncoder::IsConfigSupported`. The crash happens because `VideoEncoderConfigInternal::ToEncoderConfig` assumes that its codec string member begins with a supported codec name (which should be non-space character). When the codec string has leading spaces, this assumption is invalidated, leading to a crash. To resolve this issue, the patch removes the space-trimming in `CanEncode` and calling `IsSupportedVideoCodec` with the given codec string directly before `ToEncoderConfig`. By doing so, codec strings with leading spaces are correctly identified as "unsupported", and `ToEncoderConfig` is not invoked with invalid input, preventing the crash. Additionally, this patch adds a WPT to ensure that codec string containing spaces are reported as "unsupported" and the no crash occurs when such strings are processed. Differential Revision: https://phabricator.services.mozilla.com/D231719 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1936352 gecko-commit: 00a6b47b218e193d0018ffbd2996e0112d2a90f3 gecko-reviewers: media-playback-reviewers, alwu
and decorations." To reland the CL 5484626, added fuzziness to a reftest case. ref: https://chromium-review.googlesource.com/c/chromium/src/+/5484626 Bug: 40829719 Change-Id: I4060732e5efe446851156ae3b9bcd491ebbbab41 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6108568 Reviewed-by: Stephen Chenney <schenney@chromium.org> Commit-Queue: Gyuyoung Kim <gyuyoung@igalia.com> Reviewed-by: Gyuyoung Kim <gyuyoung@igalia.com> Cr-Commit-Position: refs/heads/main@{#1400120}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )