Update tests for DAP proximity events #2

zqzhang · 2013-09-22T08:40:30Z

Rename index.html to ProximityEvent_tests.html for further tests development
Remove license info to embrace the default W3C test suite license
Update test case names to reflect the tests
Change TypeError checking to 'new TypeError()'

Update tests for DAP proximity events

Update storagesize6xml.xml

…Events PointerEvents pages updates per WG and jacobrossi feedback

…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 <cbiesinger@chromium.org> Commit-Queue: David Grogan <dgrogan@chromium.org> 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 web-platform-tests#3 0x00007f6ee84ad7f5 in blink::LayoutFlexibleBox::UseOverrideLogicalHeightForPerentageResolution ( this=0x3dda8d434010, child=...) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1137 web-platform-tests#4 0x00007f6ee83f2b9d in blink::LayoutBlock::AvailableLogicalHeightForPercentageComputation ( this=0x3dda8d434198) at ../../third_party/blink/renderer/core/layout/layout_block.cc:2333 web-platform-tests#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 web-platform-tests#6 0x00007f6ee86dcc5c in blink::LayoutBoxUtils::AvailableLogicalHeight (box=..., cb=0x3dda8d434198) at ../../third_party/blink/renderer/core/layout/ng/layout_box_utils.cc:64 web-platform-tests#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 web-platform-tests#8 0x00007f6ee83ef53a in blink::LayoutBlock::ComputePreferredLogicalWidths (this=0x3dda8d4243d0) at ../../third_party/blink/renderer/core/layout/layout_block.cc:1509 web-platform-tests#9 0x00007f6ee8451f01 in blink::LayoutBox::MaxPreferredLogicalWidth (this=0x3dda8d4243d0) at ../../third_party/blink/renderer/core/layout/layout_box.cc:1395 web-platform-tests#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 web-platform-tests#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 web-platform-tests#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 web-platform-tests#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 <dgrogan@chromium.org> Auto-Submit: Christian Biesinger <cbiesinger@chromium.org> Reviewed-by: David Grogan <dgrogan@chromium.org> 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 <tkent@chromium.org> Commit-Queue: Mason Freed <masonfreed@chromium.org> Auto-Submit: Mason Freed <masonfreed@chromium.org> Cr-Commit-Position: refs/heads/master@{#727841}

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 <flackr@chromium.org> Reviewed-by: Kevin Ellis <kevers@chromium.org> Commit-Queue: Xida Chen <xidachen@chromium.org> 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 <masonfreed@chromium.org> Reviewed-by: Yu Han <yuzhehan@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Auto-Submit: Mason Freed <masonfreed@chromium.org> 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 <masonfreed@chromium.org> > Reviewed-by: Yu Han <yuzhehan@chromium.org> > Reviewed-by: Joey Arhar <jarhar@chromium.org> > Auto-Submit: Mason Freed <masonfreed@chromium.org> > 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 <masonfreed@chromium.org> > Reviewed-by: Yu Han <yuzhehan@chromium.org> > Reviewed-by: Joey Arhar <jarhar@chromium.org> > Auto-Submit: Mason Freed <masonfreed@chromium.org> > 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 <masonfreed@chromium.org> Commit-Queue: Mason Freed <masonfreed@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Reviewed-by: Yu Han <yuzhehan@chromium.org> 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 web-platform-tests#4 FF agrees with #2, but not web-platform-tests#4 Chrome agrees with web-platform-tests#4, but not #2 Safari agrees with web-platform-tests#4, but not #2 To me, #2 and web-platform-tests#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 <ikilpatrick@chromium.org> Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> 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 <horo@chromium.org> Reviewed-by: Hayato Ito <hayato@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Commit-Queue: Miras Myrzakerey <myrzakereyms@google.com> Cr-Commit-Position: refs/heads/master@{#875532} Co-authored-by: Miras Myrzakerey <myrzakereyms@google.com>

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 <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org> 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 <npm@chromium.org> Commit-Queue: Yoav Weiss <yoavweiss@chromium.org> Cr-Commit-Position: refs/heads/main@{#936516}

Update tests for DAP proximity events

d04e160

dontcallmedom added a commit that referenced this pull request Sep 23, 2013

Merge pull request #2 from pjckcs/dap-proximity

4bbc503

Update tests for DAP proximity events

dontcallmedom merged commit 4bbc503 into dontcallmedom:dap-proximity Sep 23, 2013

dontcallmedom pushed a commit that referenced this pull request Feb 12, 2014

Merge pull request #2 from finnle/patch-2

7f65793

Update storagesize6xml.xml

dontcallmedom pushed a commit that referenced this pull request Nov 21, 2014

Merge pull request #2 from ArtemAntonets/submission/Microsoft/Pointer…

cd0c066

…Events PointerEvents pages updates per WG and jacobrossi feedback

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update tests for DAP proximity events #2

Update tests for DAP proximity events #2

zqzhang commented Sep 22, 2013

Update tests for DAP proximity events #2

Update tests for DAP proximity events #2

Conversation

zqzhang commented Sep 22, 2013