ba9a25564533962318bba8bda7f5f5bd8d8c659a: Bug 1591894 [wpt PR 19858] - Support IPv6 literals in KURL::SetHostAndPort, a=testonly
Adam Rice <ricea@chromium.org> - Mon, 04 Nov 2019 11:12:46 +0000 - rev 564763
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1591894 [wpt PR 19858] - Support IPv6 literals in KURL::SetHostAndPort, a=testonly Automatic update from web-platform-tests Support IPv6 literals in KURL::SetHostAndPort KURL::SetHostAndPort would corrupt IPv6 literals because they contain ":" characters. Make it check for "[]" characters and use the first ":" after an IPv6 address as the start of the port number if one is present. Fixed: 1012416 Change-Id: If07a671b48c8c1b24b16883fb9072a86b0de7ebc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1871449 Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Commit-Queue: Adam Rice <ricea@chromium.org> Cr-Commit-Position: refs/heads/master@{#710668} -- wpt-commits: 5e2d3b33d4dc2d9221446c32c2fd6a3d79768406 wpt-pr: 19858 Differential Revision: https://phabricator.services.mozilla.com/D53553
2e965792fc82b6729811b28cc8041243cf2e2b19: Bug 1592137 [wpt PR 19960] - Remove inDocument check for emitting change events, a=testonly
Joey Arhar <jarhar@chromium.org> - Mon, 04 Nov 2019 11:12:41 +0000 - rev 564762
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1592137 [wpt PR 19960] - Remove inDocument check for emitting change events, a=testonly Automatic update from web-platform-tests Remove inDocument check for emitting change events The html spec does not seem to say anything against emitting change events for input elements which are detached from the DOM. It does say that immutable input elements should not have change events emitted for them, but I don't think that having it detached from the DOM means that it is immutable, especially since we can successfully change the .checked value while detached from the dom. Bug: 773680 Change-Id: Ie579ed1f3c34fc03f74554a5685f40c510805f2a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1885093 Reviewed-by: Kent Tamura <tkent@chromium.org> Reviewed-by: Mason Freed <masonfreed@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/master@{#710642} -- wpt-commits: f2f0130e56d6893099b8e0c51fc82bc2ab4b1ce2 wpt-pr: 19960 Differential Revision: https://phabricator.services.mozilla.com/D53552
6f5cc4b1c09a9a21b7f149546eeec6730288dfb7: Bug 1591536 [wpt PR 19900] - Update wpt metadata, a=testonly
moz-wptsync-bot <wptsync@mozilla.com> - Wed, 30 Oct 2019 04:15:03 +0000 - rev 564761
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1591536 [wpt PR 19900] - Update wpt metadata, a=testonly wpt-pr: 19900 wpt-type: metadata Differential Revision: https://phabricator.services.mozilla.com/D53551
38ae71a7ccd1e3856ff99053964d9bc95dddcb5d: Bug 1591536 [wpt PR 19900] - Prevent sandboxed iframe Document from sharing execution context with initial about:blank Document, a=testonly
Daniel Clark <daniec@microsoft.com> - Mon, 04 Nov 2019 11:12:32 +0000 - rev 564760
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1591536 [wpt PR 19900] - Prevent sandboxed iframe Document from sharing execution context with initial about:blank Document, a=testonly Automatic update from web-platform-tests Prevent sandboxed iframe Document from sharing execution context with initial about:blank Document This change fixes an issue where a sandboxed iframe can be created such that it contains a sandboxed Document with an opaque origin that still shares a script context with the iframe's initial un-sandboxed about:blank Document. The scenario is set up in the following manner: 1) Create a new iframe dynamically, and set its src to a same-domain page that we are going to sandbox. 2) Insert the iframe into a Document, and synchronously grab a reference to its initial about:blank Document. 3) Synchronously set iframe.sandbox = "allow-scripts" (this is still before the same-domain page has loaded in the frame). 4) The iframe’s navigation to the same-domain page occurs, asynchronously. FrameLoader::ShouldReuseDefaultView is called to determine the mode in which to load the new page. FrameLoader::ShouldReuseDefaultView fails to check the iframe’s sandbox flags (it only looks at the CSP ones), so the navigation proceeds without resetting the type system of the iframe. The result is that the newly loaded page shares the type system of the initial about:blank Document. 5) Code in the sandboxed iframe is now free to make changes to its type system that can affect any usage of the about:blank Document since they share the same type system. This is a sandbox escape in that if the same-domain page that the iframe is navigated to contains user-generated code, it could run outside the iframe. It can also result in crashes if we poke things in the right way, since an object that should be considered cross-origin can bleed into the top-level page, with the result that access checks which are never expected to fail can now fail. This change fixes the issue by making FrameLoader::ShouldReuseDefaultView() check the iframe's sandbox flags via FrameLoader::EffectiveSandboxFlags(), in addition to the existing check for CSP sandbox flags. Bug: 1017441 Change-Id: Ide1b13e16b0e0428a243ff47b6e17ae25ad0ff0d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1881315 Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Nate Chapin <japhet@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#710629} -- wpt-commits: 1da988941a8c83f13aa71447a188335f5cc35ab0 wpt-pr: 19900 Differential Revision: https://phabricator.services.mozilla.com/D53550
f083b4e515631d6dc6cd6624fd476ceb560af5cf: Bug 1590164 [wpt PR 19808] - [css-text] Use always the BreakIterator to compute the intrinsic size, a=testonly
Javier Fernandez <jfernandez@igalia.com> - Mon, 04 Nov 2019 11:12:27 +0000 - rev 564759
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1590164 [wpt PR 19808] - [css-text] Use always the BreakIterator to compute the intrinsic size, a=testonly Automatic update from web-platform-tests [css-text] Use always the BreakIterator to compute the intrinsic size As part of the preferred width computation of LayoutText objects, we have an specific function to implement the min-word-fragment of a text. We are handling the case of break-all and break-word differently, and that's right. However, we are using the BreakIterator only in case of break-all. This caused that we consider valid to break grapheme clusters when computing the min-content size, which leads to wrong values in some cases, like the one described in the bug. This CL changes the mentioned logic to rely always into the BreakIterator, which knows better when is valid to break the text. Bug: 1013775 Change-Id: Ia152d346a61b6b54eaac185a399b0d572e3aba4d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1857319 Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#710594} -- wpt-commits: ae12c777133af976a4ba1d66b138d0fa3cee24d3 wpt-pr: 19808 Differential Revision: https://phabricator.services.mozilla.com/D53549
09224e2d0e4a6109af5351a29ae084bdc4b73308: Bug 1592190 [wpt PR 19970] - [LayoutNG] Fix not to break after leading out-of-flow objects, a=testonly
Koji Ishii <kojii@chromium.org> - Mon, 04 Nov 2019 11:12:22 +0000 - rev 564758
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1592190 [wpt PR 19970] - [LayoutNG] Fix not to break after leading out-of-flow objects, a=testonly Automatic update from web-platform-tests [LayoutNG] Fix not to break after leading out-of-flow objects r694888 (crrev.com/c/1792467) gave a break opportunity after OOF objects. For leading OOF objects, there should not be a break opportunity, but the patch gave to them too. This patch fixes not to add a break opportunity if there were no preceding in-flow objects. Bug: 1018748 Change-Id: I89a8614cdfd85bed1bb8c2f3b6db892697f7add7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1886130 Commit-Queue: Koji Ishii <kojii@chromium.org> Reviewed-by: Yoshifumi Inoue <yosin@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/master@{#710527} -- wpt-commits: 6a912ffd3db259b1d6a133f589aa30c97f7738e4 wpt-pr: 19970 Differential Revision: https://phabricator.services.mozilla.com/D53548
28ecb3cd42626b8f453eb95951e1f820097e80a9: Bug 1592073 [wpt PR 19956] - Update wpt metadata, a=testonly
moz-wptsync-bot <wptsync@mozilla.com> - Wed, 30 Oct 2019 02:35:17 +0000 - rev 564757
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1592073 [wpt PR 19956] - Update wpt metadata, a=testonly wpt-pr: 19956 wpt-type: metadata Differential Revision: https://phabricator.services.mozilla.com/D53547
09a4af9b792633f2c3615d91ee44d9f95f822766: Bug 1592073 [wpt PR 19956] - [css-lists] Skip bidi controls when painting symbol markers, a=testonly
Oriol Brufau <obrufau@igalia.com> - Mon, 04 Nov 2019 11:12:14 +0000 - rev 564756
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1592073 [wpt PR 19956] - [css-lists] Skip bidi controls when painting symbol markers, a=testonly Automatic update from web-platform-tests [css-lists] Skip bidi controls when painting symbol markers Symbol markers are painted as geometric shapes, not as text. However, they are still represented by a text run, which may break into multiple fragments. To avoid painting the symbol multiple times, the symbol is painted only for the first one. Before this patch, this was simply done by checking that the 'from' data of the NGTextFragmentPaintInfo was 0. However, markers can have a non-normal unicode-bidi, because the value is inherited from the list item, or via the ::marker pseudo-element once it gets implemented. The problem is that some unicode-bidi values can insert bidi control characters like U+202A, U+202D, U+2066 or U+2068. This makes the first 'from' data to be greater than zero, so the symbol was not painted. This patch checks whether the first 'from' characters are bidi controls, if so, the symbol is painted. Otherwise it's not painted. BUG=1018696 TEST=external/wpt/css/css-lists/list-marker-symbol-bidi.html Change-Id: If5ec4eee624f27ab63df81940f1fc2ea727a5681 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1884291 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#710493} -- wpt-commits: 971bd53b84e2f7103052265afc540c54faef69ae wpt-pr: 19956 Differential Revision: https://phabricator.services.mozilla.com/D53546
90a37863fbdcc09f2885563db2dc506c6b8f1d0d: Bug 1592341 [wpt PR 19982] - [AnimationWorklet] De-flake stateful-animator tests, a=testonly
Yi Gu <yigu@chromium.org> - Mon, 04 Nov 2019 11:12:09 +0000 - rev 564755
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1592341 [wpt PR 19982] - [AnimationWorklet] De-flake stateful-animator tests, a=testonly Automatic update from web-platform-tests [AnimationWorklet] De-flake stateful-animator tests Some tests relied on time equality which could be flaky because internally the time value is converted to base::TimeTicks. Bug: 1014810 Change-Id: I9530f087c1273907af653f0d81f75569572d2e43 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1886293 Reviewed-by: Xida Chen <xidachen@chromium.org> Commit-Queue: Yi Gu <yigu@chromium.org> Cr-Commit-Position: refs/heads/master@{#710443} -- wpt-commits: aa409fcfc73c881e463fed5101b1c3c1080b8337 wpt-pr: 19982 Differential Revision: https://phabricator.services.mozilla.com/D53545
359d207cc82cf56700f1ab68ce644639d34a2a6a: Bug 1591442 [wpt PR 19889] - HTML: Add a historical test for the search event and incremental="", a=testonly
Simon Pieters <zcorpan@gmail.com> - Mon, 04 Nov 2019 11:12:02 +0000 - rev 564754
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1591442 [wpt PR 19889] - HTML: Add a historical test for the search event and incremental="", a=testonly Automatic update from web-platform-tests HTML: Add a historical test for the search event and incremental="" See https://github.com/whatwg/html/issues/667 -- wpt-commits: 3b93e8373d4091fea282bb6ae7bb0e655fe3ecd5 wpt-pr: 19889 Differential Revision: https://phabricator.services.mozilla.com/D53544
3c4bcf5279a6c15a3faf411feb24c00d2332c26e: Bug 1591652 [wpt PR 19918] - Update wpt metadata, a=testonly
moz-wptsync-bot <wptsync@mozilla.com> - Wed, 30 Oct 2019 02:02:30 +0000 - rev 564753
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1591652 [wpt PR 19918] - Update wpt metadata, a=testonly wpt-pr: 19918 wpt-type: metadata Differential Revision: https://phabricator.services.mozilla.com/D53543
82aa51d1f2af958d4d8789458be3495de452653f: Bug 1591652 [wpt PR 19918] - [html] Refactor tests, a=testonly
jugglinmike <mike@mikepennisi.com> - Mon, 04 Nov 2019 11:11:53 +0000 - rev 564752
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1591652 [wpt PR 19918] - [html] Refactor tests, a=testonly Automatic update from web-platform-tests [html] Refactor tests (#19918) testharness.js was recently extended with an API to explicitly opt-in to the "single page test" feature [1]. As per WPT RFC 28 [2], tests which do not use this API and which do not declare any subtests will soon be reported as a harness error. Update some tests which previously opted in implicitly to use the new API. Update others to instead declare a single subtest (so that they are no longer single-page tests). [1] https://github.com/web-platform-tests/wpt/pull/19449 [2] https://github.com/web-platform-tests/rfcs/blob/master/rfcs/single_test.md -- wpt-commits: efe71da0885bec25ff8466160abd4bce44bbb2f8 wpt-pr: 19918 Differential Revision: https://phabricator.services.mozilla.com/D53542
75aca9e3bb068824cec87fd90fa49eeeb398707e: Bug 1592330 [wpt PR 19981] - Remove redundant variable assignment & sort them, a=testonly
Sam Sneddon <me@gsnedders.com> - Mon, 04 Nov 2019 11:11:48 +0000 - rev 564751
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1592330 [wpt PR 19981] - Remove redundant variable assignment & sort them, a=testonly Automatic update from web-platform-tests Remove redundant variable assignment & sort them -- wpt-commits: fa4d010bf8f28fa37b7bd685cdaf873f29d71736 wpt-pr: 19981 Differential Revision: https://phabricator.services.mozilla.com/D53541
0907a4ea294c3f6fb50b73b96129252708fe8b0c: Bug 1588236 [wpt PR 19651] - [css-text] Consider breaking opportunities of inline siblings, a=testonly
Javier Fernandez <jfernandez@igalia.com> - Mon, 04 Nov 2019 11:11:43 +0000 - rev 564750
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1588236 [wpt PR 19651] - [css-text] Consider breaking opportunities of inline siblings, a=testonly Automatic update from web-platform-tests [css-text] Consider breaking opportunities of inline siblings First of all, bear in mind that this change affects only to intrinsic size computation in legacy layout. During the intrinsic size computation of blocks with inline children, we are determining the breaking opportunities for each child. When the word-break: break-word is used, each of this breaking opportunities should account for the min-content size. We only consider breakable locations for start and end if they are br elements or spaces, under auto-wrap, to compute the intrinsic size of a box. This is fine, since we are already using a break iterator to determine the min-size of each word. However, we were incorrectly summing the first_line_min_width for each inline sibling, even when they were part of the same text line. This change tries to avoid that problem by assuming that there is always a breaking opportunity after every character, since the spec now states that break-word should behave as normal and overflow-wrap: anywhere. Bug: 1013644 Change-Id: I04261b323cd029a624724363a566fccc826863af Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1856959 Reviewed-by: Koji Ishii <kojii@chromium.org> Commit-Queue: Javier Fernandez <jfernandez@igalia.com> Cr-Commit-Position: refs/heads/master@{#710359} -- wpt-commits: 87d9d891e4f0c2276cc4ad4bbd7e101a7c9b05d9 wpt-pr: 19651 Differential Revision: https://phabricator.services.mozilla.com/D53540
1595dd68bdfca7c5ac5f0779bcec92563eb3c24f: Bug 1591831 [wpt PR 19937] - [wptrunner] update links to old w3c/wptrunner repo, a=testonly
Philip Jägenstedt <philip@foolip.org> - Mon, 04 Nov 2019 11:11:38 +0000 - rev 564749
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1591831 [wpt PR 19937] - [wptrunner] update links to old w3c/wptrunner repo, a=testonly Automatic update from web-platform-tests [wptrunner] update links to old w3c/wptrunner repo After this, one occurrence of "w3c/wptrunner" still remains: https://github.com/web-platform-tests/wpt/issues/19936 -- wpt-commits: dfe3e45f8197721c8b70e488da3f514a1d636952 wpt-pr: 19937 Differential Revision: https://phabricator.services.mozilla.com/D53539
12ab992becc5a63d25e97c278932e66e680b5ded: Bug 1582760 [wpt PR 19188] - Force SIGKILL to kill the previous ended WebKitDriver, a=testonly
Pablo Saavedra <psaavedra@igalia.com> - Mon, 04 Nov 2019 11:11:33 +0000 - rev 564748
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1582760 [wpt PR 19188] - Force SIGKILL to kill the previous ended WebKitDriver, a=testonly Automatic update from web-platform-tests Force SIGKILL to kill the previous ended WebKitDriver Ensure that a non-responding Browser will be stopped: * Force a SIGKILL in the TestRunner.ensure_runner_stopped() * The `WebDriverServer.stop_runner()` honors the force parameter. -- wpt-commits: 743341289390430c5f5e2d2b9e74f760f8d5426a wpt-pr: 19188 Differential Revision: https://phabricator.services.mozilla.com/D53538
180f1175a6fe47a5f7001eb2e0a4b853d7088e66: Bug 1592003 [wpt PR 19952] - [ci] Emit changes to built website in logs, a=testonly
Mike Pennisi <mike@mikepennisi.com> - Mon, 04 Nov 2019 11:11:28 +0000 - rev 564747
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1592003 [wpt PR 19952] - [ci] Emit changes to built website in logs, a=testonly Automatic update from web-platform-tests [ci] Emit changes to built website in logs -- wpt-commits: d151c8a59c90086057185c240e679095fd0ef475 wpt-pr: 19952 Differential Revision: https://phabricator.services.mozilla.com/D53537
b2cef7ebf770ed8e108b7f471737e16b095e2a0b: Bug 1490228 [wpt PR 12944] - Use document.scrollingElement to access scroll properties of the view…, a=testonly
Frédéric Wang <fwang@igalia.com> - Mon, 04 Nov 2019 11:11:23 +0000 - rev 564746
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1490228 [wpt PR 12944] - Use document.scrollingElement to access scroll properties of the view…, a=testonly Automatic update from web-platform-tests Use document.scrollingElement to access scroll properties of the view… (#12944) Use document.scrollingElement to access scroll properties of the viewport See https://drafts.csswg.org/cssom-view/#dom-document-scrollingelement Found with the following command: find . -type f | xargs egrep 'document.body.scroll|document.documentElement.scroll' -- wpt-commits: 251ec7054bfe6c5665b9464238dd4baffa89dbce wpt-pr: 12944 Differential Revision: https://phabricator.services.mozilla.com/D53536
3ee76345e9a807f60c43c056b7098e9effa0a486: Bug 1591857 [wpt PR 19942] - Update wpt metadata, a=testonly
moz-wptsync-bot <wptsync@mozilla.com> - Tue, 29 Oct 2019 08:50:21 +0000 - rev 564745
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1591857 [wpt PR 19942] - Update wpt metadata, a=testonly wpt-pr: 19942 wpt-type: metadata Differential Revision: https://phabricator.services.mozilla.com/D53535
46eaf54b8e0fa2f1f46c4a7a44c5291abcb9ef3f: Bug 1591857 [wpt PR 19942] - [WebNFC] Add tests for unformatted NDEF tag, a=testonly
Wanming Lin <wanming.lin@intel.com> - Mon, 04 Nov 2019 11:11:14 +0000 - rev 564744
Push 12351 by ffxbld-merge at Mon, 02 Dec 2019 11:32:26 +0000
Bug 1591857 [wpt PR 19942] - [WebNFC] Add tests for unformatted NDEF tag, a=testonly Automatic update from web-platform-tests [WebNFC] Add tests for unformatted NDEF tag This CL adds a few tests to cover various checkpoints: - Read/write data from/to an unformatted NDEF tag, as well as interaction with NDEFPushOptions.overwrite attribute. - Read/write data from/to a non-NDEF tag, throws error. Relevant discussion in spec: https://github.com/w3c/web-nfc/issues/367 Bug: 520391, 1012463 Change-Id: I87cb7dc4611f8575b5616ecd98cc64249d79c4db Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1880537 Commit-Queue: Wanming Lin <wanming.lin@intel.com> Reviewed-by: François Beaufort <beaufort.francois@gmail.com> Reviewed-by: Leon Han <leon.han@intel.com> Cr-Commit-Position: refs/heads/master@{#710249} -- wpt-commits: e44f20914735498a05fc835efe3e2cbde9f86f00 wpt-pr: 19942 Differential Revision: https://phabricator.services.mozilla.com/D53534
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip