DO NOT MERGE - Force failures #2

jugglinmike · 2018-07-12T17:28:05Z

No description provided.

f0e1aa75a7 Merge pull request #2 from cclauss/modernize-Python-2-codes 08bedeaf9d Use print() function in both Python 2 and Python 3 git-subtree-dir: css/tools/apiclient git-subtree-split: f0e1aa75a7113c2df87ab76cdf6734e77dfbaeb7

chromedriver doesn't allow changing Object.prototype to add enumerable properties, but this test requires setting some values on Object.prototype. When Object.prototype.a is set to: {b: {c: 'on proto'}} chromedriver fails with: JavascriptErrorException: javascript error (500): Maximum call stack size exceeded (Session info: chrome=72.0.3626.121) Remote-end stacktrace: #0 0x563ff3a32a59 <unknown> #1 0x563ff39cb7f3 <unknown> #2 0x563ff38fcd7c <unknown> #3 0x563ff38ff78c <unknown> #4 0x563ff38ff5f7 <unknown> #5 0x563ff38ffbe7 <unknown> #6 0x563ff38fff1b <unknown> #7 0x563ff38a3f7a <unknown> #8 0x563ff3899bf2 <unknown> #9 0x563ff38a37b7 <unknown> #10 0x563ff3899ac3 <unknown> #11 0x563ff38782d2 <unknown> #12 0x563ff3879112 <unknown> #13 0x563ff39fe865 <unknown> web-platform-tests#14 0x563ff39ff32b <unknown> web-platform-tests#15 0x563ff39ff70c <unknown> web-platform-tests#16 0x563ff39d940a <unknown> web-platform-tests#17 0x563ff39ff997 <unknown> web-platform-tests#18 0x563ff39e9947 <unknown> web-platform-tests#19 0x563ff3a1a800 <unknown> web-platform-tests#20 0x563ff3a3c8be <unknown> web-platform-tests#21 0x7f3bf4545494 start_thread web-platform-tests#22 0x7f3bf2d58a8f clone Ran 1 tests finished in 2.0 seconds. • 0 ran as expected. 0 tests skipped. • 1 tests had errors unexpectedly Work around this problem by cleaning up the test environment so Object.prototype no longer has the override by the time chromedriver tries to inspect the test result. While here, fix the other tests to use the t.add_cleanup() function so they'll cleanup their test environment in case they exit in some other way besides reaching t.done(). The underlying chromedriver issue is tracked upstream at https://crbug.com/chromedriver/2555. Bug: 934844 Change-Id: Id1b4ab2a908bfbc001e2a2d045eeec3ef01c24d9

We used to commit navigation after receiving the first byte of document response. This CL moves commit earlier, synchronously done from CommitNavigation call. The change should not be web-observable, but some internal assumptions may have been affected. Test changes: - ReplacingDocumentLoaderFiresLoadEvent was testing the old behavior, which is not applicable anymore. - MultiChunkWithReentrancy now uses a different method to trigger reentrancy (pdf plugin), since we no longer commit after first byte. - backdrop-object.html and anchor-change-href.svg relied on test finishing late enough, now they wait for onload to eliminate a race. - use-property-synchronization-crash.html now reports an error message synchronously and therefore has JS stack and a line number. - setting-allowpaymentrequest-timing.https.sub.html has a race as explained here [1], and now fails even without site isolation. This corresponds to the step 8.b from the doc linked to the bug. Difference from attempt #1 (https://chromium-review.googlesource.com/c/1399447): - PluginDocumentParser and MediaDocumentParser early return if not parsing before accessing GetDocument. This is because DocumentLoader calls Finish() even after parser was stopped/detached. For example in Document::Abort we cancel parsing, but committed DocumentLoader might be still receiving data. We should ideally clean up all calls into parser, there are numerous TODOs for that. - pageload-image-in-popup.html relies on small image being parsed in the same task as navigation commit. Using onload seems to fix the issue. - touch-handler-iframe-plugin-assert.js hopes that onload for about:blank happens after test has finished, which is racy now. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=819800#c6 Bug: 855189, 937639, 836242, 937358 Change-Id: I65048a27e6d249a608d4eb61e5c882292386026e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1506663 Commit-Queue: Dmitry Gozman <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Arthur Sonzogni <[email protected]> Cr-Commit-Position: refs/heads/master@{#639992}

All tests pass, and crashes no longer happen. I believe that code will not longer crash, but there might be futher instances of incorrect positioning. Fix #1 LayoutDescendantCandidates did not sweep newly discovered candidates. This was done manually once inside NGOutOfFlowLayoutPart::Run, and sweep was not performed for LayoutDescendantCandidates found in Legacy. Fix is to make LayoutDescendantCandidates perform sweep instead. Fix #2 fix #1 exposed a bug where duplicate fragments were generated for a single layout object. This happened when NG was generating fragments not inside ContainingBlock. Fix one instance of this inside NGOutOfFlowLayoutPart::IsContainingBlockForDescendant by making sure that OOF with inline containers are only positioned inside its ContainingBlock() Fix #3 NGOutOfFlowLayoutPart::LayoutDescendant offset adjustment. Bug: 935805 Change-Id: I9f7ebbc7223f40fbbf6ba3739d9385bfd59e3641 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1517093 Commit-Queue: Aleks Totic <[email protected]> Reviewed-by: Morten Stenshorne <[email protected]> Reviewed-by: Koji Ishii <[email protected]> Cr-Commit-Position: refs/heads/master@{#641628}

This reverts commit 712c3cf3ed8201420acf23f760eaa34be20781cd. Reason for revert: This patch causes webkit-layout-tests failure on WebKit_Linux_Trusty_ASAN bot: https://ci.chromium.org/p/chromium/builders/ci/WebKit%20Linux%20Trusty%20ASAN/25720 Unexpected Failures: * external/wpt/css/css-scroll-snap/scroll-snap-type.html * virtual/threaded/external/wpt/css/css-scroll-snap/scroll-snap-type.html STDERR: ==1==ERROR: AddressSanitizer: heap-use-after-free on address 0x61200023f8d8 at pc 0x5620c924e56d bp 0x7ffde3c56830 sp 0x7ffde3c56828 STDERR: READ of size 8 at 0x61200023f8d8 thread T0 (content_shell) STDERR: #0 0x5620c924e56c in get ./../../base/memory/scoped_refptr.h:212:27 STDERR: #1 0x5620c924e56c in Style ./../../third_party/blink/renderer/core/layout/layout_object.h:1615:0 STDERR: #2 0x5620c924e56c in GetPhysicalSnapType ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:88:0 STDERR: #3 0x5620c924e56c in blink::SnapCoordinator::UpdateSnapContainerData(blink::LayoutBox&) ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:107:0 STDERR: #4 0x5620c924e74b in blink::SnapCoordinator::UpdateAllSnapContainerData() ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:76:5 Original change's description: > Correctly handle scroll-snap-type changes to 'none' > > > Previously when a scroll container's snap type is changed to 'none' its > data was discarded including all of its snap areas. However this is > incorrect. Because while the snap type is 'none', the element is still > a scroll container which per spec [1] means that is should continue to > captures the snap areas in its subtree for whom it is the nearest > ancestor scroll container . The only difference is that it no longer > snaps. > > The fix is that we no longer remove the snap container data just > because is has a 'none' snap type and instead keep it and its snap > areas. But we check the snap type before performing any snap. > > To ensure this does not introduce any performance regression, this CL > also includes an optimization where we avoid re-calculating > snap_container_data when the snap type is 'none'. So keeping these snap > data should not be cheap. > > Note that there is another problem where if the current snap container > is no longer a scroll container (e.g., overflow: scroll => overflow: > visible) we release its snap areas and they become "orphan". But if we > are to do this correctly, we should re-assign these areas to the next > stroller in the chain. Similarly when an element becomes a scroll > container, it can potentially take over snap areas from its parent snap > container. > > > This patch does not address that situation yet but fixes the easier > problem. > > [1] https://drafts.csswg.org/css-scroll-snap/#overview > > Bug: 953575 > Test: > - wpt/css/css-scroll-snap/scroll-snap-type-change.html => Changing snap-type should work correctly > - wpt/css/css-scroll-snap/scroll-snap-type.html => Add a specific test for type 'none' to ensure it does not snap > > Change-Id: Ie493ad68ecba818ed41c0ee103ccf44725ff6e3f > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1589899 > Reviewed-by: Majid Valipour <[email protected]> > Reviewed-by: David Bokan <[email protected]> > Commit-Queue: Majid Valipour <[email protected]> > Cr-Commit-Position: refs/heads/master@{#657460} [email protected],[email protected] Change-Id: I3a327f6e342e95d045194d24ceaf49de52b2b921 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 953575 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1600437 Reviewed-by: Takashi Sakamoto <[email protected]> Commit-Queue: Takashi Sakamoto <[email protected]> Cr-Commit-Position: refs/heads/master@{#657571}

Issue #1: The "SecureContext" IDL attribute considers localhost to be secure, but the Cookie Store API assumed that it would only be exposed on cryptographically secure origins, so a DCHECK caused attempts to set/delete cookies on http://localhost to crash. This CL replaces the DCHECK with an exception that is thrown on attempts to set/delete secure cookies on cryptographically insecure origins. Issue #2: The "secure" cookie attribute defaulted to true. Setting/deleting a secure cookie on a cryptographically insecure origin is prohibited. The cookieStore.delete() API excluded the option to set the "secure" attribute, however, so there was no way to delete an insecure cookie. This CL defaults the "secure" attribute to true on cryptographically secure origins, and false otherwise. Bug: 956641 Change-Id: Iff7c22713e8604d60b68d42199a74b2d08235712 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1700357 Commit-Queue: Staphany Park <[email protected]> Reviewed-by: Victor Costan <[email protected]> Cr-Commit-Position: refs/heads/master@{#681054}

Bug is: <container overflow:scroll> <target transform:scale(1)> Initially, container's scrollbars are disabled. When target changes its scale and grows outside of container, scrollbars were not updated. Fix #1 is to call UpdateScrollbarEnabledState. This resulted in scrollbars being painted, but not clickable. Fix #2, calling UpdateScrollableAreaSet makes scrollbars clickable too. Fix #2 was an educated guess. Bug: 926167 Change-Id: I02454047c87aaecede9c56db1c02bbd1b21b15c5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1704218 Commit-Queue: Aleks Totic <[email protected]> Reviewed-by: Stefan Zager <[email protected]> Cr-Commit-Position: refs/heads/master@{#681091}

…the WPT innerText getter test. Depends on D45159 Differential Revision: https://phabricator.services.mozilla.com/D46186 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1241631 gecko-commit: 4dc6ff8d58b31c747e519abcbe01270d01d66636 gecko-integration-branch: autoland gecko-reviewers: mats

It should only be definite if the element already had a definite main size or if the container has a definite main size. This is #2 from https://drafts.csswg.org/css-flexbox/#definite-sizes Bug: 845235 Change-Id: I0230080d22ada93ebc8bae09aeda629d87cf5b6d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1797442 Reviewed-by: Christian Biesinger <[email protected]> Commit-Queue: David Grogan <[email protected]> Cr-Commit-Position: refs/heads/master@{#698790}

…iner height See stack trace below. We set the override container logical height to -1 for the initial layout of a flex item so that we compute the correct size for min-height. However, that messes with our cache for definite heights because we would always set it to indefinite in such a case. Instead, just don't cache these values. That way we will later compute the right thing for resolving flex-basis, etc. (FlexNG can't come soon enough...) #0 blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (this=0x3dda8d434198, out_cb=0x7f6e7d42d8c0, out_skipped_auto_height_containing_block=0x0) at ../../third_party/blink/renderer/core/layout/layout_box.cc:3833 #1 0x00007f6ee84ad0a1 in blink::LayoutFlexibleBox::MainAxisLengthIsDefinite (this=0x3dda8d434010, child=..., flex_basis=Length(0%, Percent), add_to_cb=false) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:762 #2 0x00007f6ee84af930 in blink::LayoutFlexibleBox::MainSizeIsDefiniteForPercentageResolution ( this=0x3dda8d434010, child=...) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1125 #3 0x00007f6ee84ad7f5 in blink::LayoutFlexibleBox::UseOverrideLogicalHeightForPerentageResolution ( this=0x3dda8d434010, child=...) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1137 #4 0x00007f6ee83f2b9d in blink::LayoutBlock::AvailableLogicalHeightForPercentageComputation ( this=0x3dda8d434198) at ../../third_party/blink/renderer/core/layout/layout_block.cc:2333 #5 0x00007f6ee845e745 in blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution ( this=0x3dda8d4243d0, out_cb=0x0, out_skipped_auto_height_containing_block=0x0) at ../../third_party/blink/renderer/core/layout/layout_box.cc:3830 #6 0x00007f6ee86dcc5c in blink::LayoutBoxUtils::AvailableLogicalHeight (box=..., cb=0x3dda8d434198) at ../../third_party/blink/renderer/core/layout/ng/layout_box_utils.cc:64 #7 0x00007f6ee86eafea in blink::LayoutNGMixin<blink::LayoutBlockFlow>::ComputeIntrinsicLogicalWidths ( this=0x3dda8d4243d0, min_logical_width=0px, max_logical_width=0px) at ../../third_party/blink/renderer/core/layout/ng/layout_ng_mixin.cc:48 #8 0x00007f6ee83ef53a in blink::LayoutBlock::ComputePreferredLogicalWidths (this=0x3dda8d4243d0) at ../../third_party/blink/renderer/core/layout/layout_block.cc:1509 #9 0x00007f6ee8451f01 in blink::LayoutBox::MaxPreferredLogicalWidth (this=0x3dda8d4243d0) at ../../third_party/blink/renderer/core/layout/layout_box.cc:1395 #10 0x00007f6ee84adba2 in blink::LayoutFlexibleBox::ComputeInnerFlexBaseSizeForChild (this=0x3dda8d434198, child=..., main_axis_border_and_padding=0px, child_layout_type=blink::LayoutFlexibleBox::kForceLayout) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:890 #11 0x00007f6ee84ae5d1 in blink::LayoutFlexibleBox::ConstructAndAppendFlexItem (this=0x3dda8d434198, algorithm=0x7f6e7d42ed70, child=..., layout_type=blink::LayoutFlexibleBox::kForceLayout) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1203 #12 0x00007f6ee84aa27b in blink::LayoutFlexibleBox::LayoutFlexItems (this=0x3dda8d434198, relayout_children=true, layout_scope=...) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:934 #13 0x00007f6ee84a9cff in blink::LayoutFlexibleBox::UpdateBlockLayout (this=0x3dda8d434198, relayout_children=true) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:369 Bug: 1019138 Change-Id: Ie94e69a5f3fe6accc3623d358315b174088d5597 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1902514 Commit-Queue: David Grogan <[email protected]> Auto-Submit: Christian Biesinger <[email protected]> Reviewed-by: David Grogan <[email protected]> Cr-Commit-Position: refs/heads/master@{#713296}

With this CL, recursive custom element constructions are no longer allowed. I.e. this will now only run the constructor once: class extends HTMLElement { constructor() { super(); customElements.upgrade(this); } } Previously, the code and spec had a bug which caused the above code snippet to infinitely recurse. In [1] the spec has changed, to set the custom element state to "failed" before the constructor is called. With this change in place, recursive calls will early-out at step #2 (of [2]), and avoid the recursion. [1] whatwg/html#5126 [2] https://html.spec.whatwg.org/multipage/custom-elements.html#upgrades Bug: 966472 Change-Id: I76e88c0b70132eee2482c304ef9e727ae1fe8fc7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1931644 Reviewed-by: Kent Tamura <[email protected]> Commit-Queue: Mason Freed <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/master@{#727841}

Patch #2: Parsing and validating the parameters of CanMakePaymentEvent.respondWithMinimalUI() in Blink. The respondWithMinimalUI() method is disabled by default and can be enabled via chrome://flags/#enable-experimental-web-platform-features. Explainer: https://gist.github.com/rsolomakhin/eba91c185028899883d2c7f37f357d7c Demo: https://rsolomakhin.github.io/pr/apps/micro/ Test: wpt/payment-handler/respond-with-minimal-ui.https.html Chrome feature status: https://chromestatus.com/feature/5661524146257920 Blink-dev intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/kTLpgFJz6Ck/IQeiGDtOAwAJ Bug: 1005076 Change-Id: I1573cef83d357046144d198e870c7f3fd54fd976 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2072582 Reviewed-by: Danyao Wang <[email protected]> Commit-Queue: Rouslan Solomakhin <[email protected]> Cr-Commit-Position: refs/heads/master@{#745010}

When animating font-affecting properties (e.g. font-size) while the base style contains font-relative units (e.g. em), we can not use the base computed style optimization, since the font-relative units in the base must respond to the font animation. A has_font_affecting_animation_ flag was recently added to ElementAnimations to assist in disabling the optimization under these circumstances. However, that was added with an insufficient understanding of ElementAnimation's lifetime, and hence this flag doesn't really work properly. For example, if we have an animation that initially doesn't affect the font, but then suddenly affects the font after all via setKeyframes, we would paint one incorrect frame before discovering that the font is now affected, and then (for frame #2 and subsequent) we'd be able to disable the optimization. This CL instead checks if the EffectStack affects the font when we're considering the base computed style for use. Bug: 437689 Change-Id: If07f1e82559673433be0a80d2c3edea1c1a5165a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2139662 Reviewed-by: Robert Flack <[email protected]> Commit-Queue: Anders Hartvoll Ruud <[email protected]> Cr-Commit-Position: refs/heads/master@{#759197}

Paint worklet already works with custom property animation running on the compositor thread, the requirement is that we need “will-change: transform” for the paint worklet element. Without that, the custom property animation will run on the main thread, such as this example: https://output.jsbin.com/muwiyux/quiet. This CL makes changes such that a custom property animation will always be composited as long as it is used by paint worklet, even if the element doesn't have "will-change: transform". The change is actually small, there are only two things we need: 1. Start the animation on compositor. 2. Ensure the compositor ticks the animation. For #1, we add a "has_paint_worklet_with_custom_prop_anim" in the Animation::PreCommit, when it is true, we always composite the animation. For #2, we give a special ElementId which is uint64_t::max() to the paint worklet element, and on the CC side, once we see that element id, we know that the animation associated with that should be ticking even if the element id doesn't have anything associated on the property tree. Bug: 987969 Change-Id: Ia849640065470e529a2b8d23a4b7b74339831c48 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2359370 Reviewed-by: Robert Flack <[email protected]> Reviewed-by: Kevin Ellis <[email protected]> Commit-Queue: Xida Chen <[email protected]> Cr-Commit-Position: refs/heads/master@{#812056}

There were some crashes caused by nested slots (e.g. <slot><slot>Content</slot></slot>) being removed from the tree. These crashes were triggered by [1], which removed Shadow DOM v0, but my theory is that due to the old V0 shadow root code, more calls were being made to SlotAssignment::RecalcAssignment(). Now that the V0 code is gone, it has exposed some missing code. Three issues are being fixed here: 1. In Node::CheckSlotChange(), while removing the inner nested slot, the parent_slot will have already been removed from the tree, so we only need to call DidSlotChange if not. This used to be a DCHECK. 2. In TreeOrderedMap::Get(), while removing a key that previously had more than one element, we may walk the tree and find that none of the pre-existing elements are present. I.e. we're in a RemoveScope. In this case, the key should be removed from the map. 3. In SlotAssignment::DidRemoveSlotInternal(), given #2 above, we can just early-out if the slot isn't present in the map. I added a test for the crash conditions (variations on removing nested named and unnamed slots), plus I added a test for the TreeOrderedMap class, since there was none previously. The last test in the set documents the new Get() behavior. I also tried to improve some of the comments along the way. Finally, this CL rolls back a mitigation [2] previously landed for this crash. [1] https://chromium-review.googlesource.com/c/chromium/src/+/2586019 [2] https://chromium-review.googlesource.com/c/chromium/src/+/2595967 Bug: 1159328, 1159727 Change-Id: I47fbf33b2313b9ae2efe229443af6e8c9a1920a9 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2597040 Commit-Queue: Mason Freed <[email protected]> Reviewed-by: Yu Han <[email protected]> Reviewed-by: Joey Arhar <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/master@{#838974}

…owRoot" This reverts commit dbfed21f94881a2918223792ebde3476b8fd69e6. Reason for revert: Findit (https://goo.gl/kROfz5) identified CL at revision 838974 as the culprit for failures in the build cycles as shown on: https://analysis.chromium.org/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyRAsSDVdmU3VzcGVjdGVkQ0wiMWNocm9taXVtL2RiZmVkMjFmOTQ4ODFhMjkxODIyMzc5MmViZGUzNDc2YjhmZDY5ZTYM Sample Failed Build: https://ci.chromium.org/b/8860163671563368608 Sample Failed Step: webkit_unit_tests Original change's description: > Fix several crashes when nested slots are removed from a ShadowRoot > > There were some crashes caused by nested slots (e.g. > <slot><slot>Content</slot></slot>) being removed from the tree. > These crashes were triggered by [1], which removed Shadow DOM v0, but > my theory is that due to the old V0 shadow root code, more calls were > being made to SlotAssignment::RecalcAssignment(). Now that the V0 code > is gone, it has exposed some missing code. > > Three issues are being fixed here: > 1. In Node::CheckSlotChange(), while removing the inner nested slot, > the parent_slot will have already been removed from the tree, so we > only need to call DidSlotChange if not. This used to be a DCHECK. > 2. In TreeOrderedMap::Get(), while removing a key that previously had > more than one element, we may walk the tree and find that none of > the pre-existing elements are present. I.e. we're in a RemoveScope. > In this case, the key should be removed from the map. > 3. In SlotAssignment::DidRemoveSlotInternal(), given #2 above, we can > just early-out if the slot isn't present in the map. > > I added a test for the crash conditions (variations on removing nested > named and unnamed slots), plus I added a test for the TreeOrderedMap > class, since there was none previously. The last test in the set > documents the new Get() behavior. I also tried to improve some of the > comments along the way. Finally, this CL rolls back a mitigation [2] > previously landed for this crash. > > [1] https://chromium-review.googlesource.com/c/chromium/src/+/2586019 > [2] https://chromium-review.googlesource.com/c/chromium/src/+/2595967 > > Bug: 1159328, 1159727 > Change-Id: I47fbf33b2313b9ae2efe229443af6e8c9a1920a9 > Cq-Do-Not-Cancel-Tryjobs: true > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2597040 > Commit-Queue: Mason Freed <[email protected]> > Reviewed-by: Yu Han <[email protected]> > Reviewed-by: Joey Arhar <[email protected]> > Auto-Submit: Mason Freed <[email protected]> > Cr-Commit-Position: refs/heads/master@{#838974} Change-Id: I97202c545f74df090124e82775fe79ce978d3d63 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 1159328, 1159727 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2601758 Cr-Commit-Position: refs/heads/master@{#839038}

…owRoot" This is a reland of dbfed21f94881a2918223792ebde3476b8fd69e6 --> Patchset 2 contains the fix, just a missing initializer on an int in the test. Original change's description: > Fix several crashes when nested slots are removed from a ShadowRoot > > There were some crashes caused by nested slots (e.g. > <slot><slot>Content</slot></slot>) being removed from the tree. > These crashes were triggered by [1], which removed Shadow DOM v0, but > my theory is that due to the old V0 shadow root code, more calls were > being made to SlotAssignment::RecalcAssignment(). Now that the V0 code > is gone, it has exposed some missing code. > > Three issues are being fixed here: > 1. In Node::CheckSlotChange(), while removing the inner nested slot, > the parent_slot will have already been removed from the tree, so we > only need to call DidSlotChange if not. This used to be a DCHECK. > 2. In TreeOrderedMap::Get(), while removing a key that previously had > more than one element, we may walk the tree and find that none of > the pre-existing elements are present. I.e. we're in a RemoveScope. > In this case, the key should be removed from the map. > 3. In SlotAssignment::DidRemoveSlotInternal(), given #2 above, we can > just early-out if the slot isn't present in the map. > > I added a test for the crash conditions (variations on removing nested > named and unnamed slots), plus I added a test for the TreeOrderedMap > class, since there was none previously. The last test in the set > documents the new Get() behavior. I also tried to improve some of the > comments along the way. Finally, this CL rolls back a mitigation [2] > previously landed for this crash. > > [1] https://chromium-review.googlesource.com/c/chromium/src/+/2586019 > [2] https://chromium-review.googlesource.com/c/chromium/src/+/2595967 > > Bug: 1159328, 1159727 > Change-Id: I47fbf33b2313b9ae2efe229443af6e8c9a1920a9 > Cq-Do-Not-Cancel-Tryjobs: true > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2597040 > Commit-Queue: Mason Freed <[email protected]> > Reviewed-by: Yu Han <[email protected]> > Reviewed-by: Joey Arhar <[email protected]> > Auto-Submit: Mason Freed <[email protected]> > Cr-Commit-Position: refs/heads/master@{#838974} Bug: 1159328 Bug: 1159727 Change-Id: I0025c0f00d6b3876de8f40a60fdc34f726ddc85c Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2601051 Auto-Submit: Mason Freed <[email protected]> Commit-Queue: Mason Freed <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Reviewed-by: Joey Arhar <[email protected]> Reviewed-by: Yu Han <[email protected]> Cr-Commit-Position: refs/heads/master@{#839148}

As per https://github.com/web-platform-tests/rfcs/blob/master/rfcs/py_3.md, step #2 of the transition to Python 3-only is to make 'wpt ...' commands run in Python 3 by default. Passing --py2 will now be necessary to run under Python 2. (Until ~Feb 2021, when we will remove py2 support entirely). This does affect some CI runs. Cases where they already specified py3 will remain py3. Cases which are designed to run under py2 had `--py2` added. Cases that didn't currently specify and aren't version specific are upgraded from py2 to py3 (one example is Azure Pipelines Mac infrastructure tests.) Some Azure Pipelines helper scripts are used for both py2 and py3 tasks. As a simple way to keep them working, `--py2` is used for them as it is always available.

2 tests in this test suite seem inconsistent: test#2 asserts that tbody.height=10px > tr.height=1px > td.height=1px implies td.offsetHeight = 1px test#4 asserts that tbody.height=10px > tr > td.height=1px implies td.offsetHeight = 10px Edge 17 is the only browser that agrees with #2 and #4 FF agrees with #2, but not #4 Chrome agrees with #4, but not #2 Safari agrees with #4, but not #2 To me, #2 and #4 seem to be in conflict. Either tbody height propagates to rows, or it does not. The problem is that #2 is overconstrained. My suggestion is that tbody height always propagates to tr. Bug: 958381 Change-Id: I28bfd108c67968d31d0372b536c316c997d2d958 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2586097 Reviewed-by: Ian Kilpatrick <[email protected]> Commit-Queue: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/master@{#845515}

…eb-platform-tests#28617) Subresource Web Bundles. The problem is: when Web Bundle fetching fails due to a network error, Subresource fetch doesn't fail forever. One such case (subresource-loading-cors-error test) was timing out previously but passes successfully with this change. This CL also adds 2 WPT tests: 1. subresource-loading-network-error.https.tentative.sub.html 2. subresource-loading-web-bundle-fetch-failed.https.tentative.html Test #1 is a scenario with a different network error than the CORS one, but with the same issue of subresource fetching timing out without the change. It passes successfully after the change. Test #2 is a scenario with a Web bundle not found error, which is not directly influenced by the code added in this CL, but it expands the test coverage which was found to be lacking the error cases before. Bug: 1168449 Change-Id: Ia3abb967e36274becc86e317bc51b1272d3ae679 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2826001 Reviewed-by: Tsuyoshi Horo <[email protected]> Reviewed-by: Hayato Ito <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Commit-Queue: Miras Myrzakerey <[email protected]> Cr-Commit-Position: refs/heads/master@{#875532} Co-authored-by: Miras Myrzakerey <[email protected]>

1. Use GetWithoutInvalidation() instead of Get() in DCHECKs. We should never call Get() inside of a DCHECK(), because this can lead to a different code path depending on whether DCHECKs are enabled. 2. Get() should not cause immediate side effects. At most, it should queue up an invalidation for later processing. Fixing #1 and #2 were required in order to get past a first set of errors introduced by the new test. 3. The actual fix -- avoid infinite loop by calling a special new SlotAssignmentWillChange(), rather than ChildrenChanged(), where a minimal GetWithoutInvalidation() is called that does not lead to IsShadowContentRelevantForAccessibility() => FirstChild() => RecalcAssignedNodes() => ChildrenChanged() ... (infinite loop). A simpler potential fix is in CL:2965317 but requires more research. It's also mentioned in a TODO comment. Bug: 1219311 Change-Id: Iafaa289f241a851404ce352715d2970172a2e5f8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2961158 Reviewed-by: Joey Arhar <[email protected]> Reviewed-by: Mason Freed <[email protected]> Reviewed-by: Dominic Mazzoni <[email protected]> Commit-Queue: Aaron Leventhal <[email protected]> Cr-Commit-Position: refs/heads/master@{#892778}

This is a manual reland of https://chromium-review.googlesource.com/c/chromium/src/+/3247449 The difference from the previous reland is that the browser tests now include 2 separate timeouts and a double rAF, to ensure that the presentation timestamp taken is far enough from both the time the first frame is sent as well as from the time the second frame is sent. More importantly, the test now actually is looking at the UKM metric, rather than at the histogram. Original change's description: > [LCP] Add animated image support > > This CL adds support for better handling of animated images in LCP: > * A new attribute is exposing the first animated frame's paint time > (behind a flag). > * `startTime` is not changed. > * The PageLoadMetrics reported for LCP are set to that first frame paint > time for animated images (behind another flag). > * Entries are not emitted until the image is loaded. > > Relevant spec issue: > w3c/largest-contentful-paint#83 Bug: 1260953 Change-Id: I34070bd90a74ed44281da63b547f13d9669f389b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3250690 Reviewed-by: Nicolás Peña Moreno <[email protected]> Commit-Queue: Yoav Weiss <[email protected]> Cr-Commit-Position: refs/heads/main@{#936516}

DO NOT MERGE - Force failures

45d4aff

jugglinmike closed this Jul 12, 2018

jugglinmike deleted the force-failure branch July 12, 2018 17:29

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DO NOT MERGE - Force failures #2

DO NOT MERGE - Force failures #2

jugglinmike commented Jul 12, 2018

DO NOT MERGE - Force failures #2

DO NOT MERGE - Force failures #2

Conversation

jugglinmike commented Jul 12, 2018