Update tests for DAP ambient light events #1

zqzhang · 2013-09-22T08:39:05Z

Rename index.html to DeviceLight_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()'
Use isNaN() to check unrestricted double value NaN

Update tests for DAP ambient light events

Update storagesize1html.html

Fix a few review issues

focus test only on empty string exchange

…set #1 id:1 of https://codereview.chromium.org/2651533003/ ) Reason for revert: This commit was intended to be reverted to test how WPT Export handles reverted changes. See the bug for more context. Original issue's description: > Create a change in external/wpt meant to be reverted > > This is to test reverted changes in the WPT Export process. > > BUG=679951 > > Review-Url: https://codereview.chromium.org/2651533003 > Cr-Commit-Position: refs/heads/master@{#445651} > Committed: https://chromium.googlesource.com/chromium/src/+/b156b16a00574a89d85ccb034b30cdfd9cc5676a TBR=qyearsley@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=679951 Review-Url: https://codereview.chromium.org/2657613002 Cr-Commit-Position: refs/heads/master@{#445762}

Revert of Create a change in external/wpt meant to be reverted (patchset #1 id:1 of https://codereview.chromium.org/2651533003/ )

…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}

Intent-to-ship approval: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/4DC56FN3paU Changes are: 1. The background of the root element paints into the property tree state that includes the local border box effect state of the root element. 2. If #1 is happening, paint a separate backdrop in the ContentsProperties state of the LayoutView, to allow effects, clips and transforms of the root element to apply via PaintChunksToCcLayer. Bug: 898293,988446,1029170,711955 Change-Id: I751e3f9c23d0b06a31cf1b13c3853180bc7ac7e6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1979258 Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#733661}

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}

This change: 1) Exposes as static synchronous helpers the WebCodecs MakeMediaConfig methods' internals so that MediaSource can use them to obtain media::{Audio,Video}DecoderConfigs from WebCodecs {Audio,Video}DecoderConfigs. 2) Implements MediaSource::AddSourceBufferUsingConfig for encoded configs (not decodedMediaType), plumbing the media decoder config through the usual steps in MSE addSourceBuffer, and through new methods in WebMediaSource and WebMediaSourceImpl to let ChunkDemuxer::AddId know it will be expected to handle WebCodecs encoded chunk appends for the associated SourceBuffer. 3) Adds a tentative folder for MSE-for-WebCodecs web_tests and adds a test for the current behavior of addSourceBuffer(webcodecs decoder config) that this CL adds. Later changes will continue plumbing of the configs in ChunkDemuxer and SourceBufferState, and also add implementations and ChunkDemuxer/etc support for appendEncoded{Audio,Video}Chunks. The h264 parser and avcc conditionally created in #1, above, could then be used by SourceBuffer processing of appended EncodedVideoChunks, too. BUG=1144908 Change-Id: I90c1d90c3a28d5cc1e33b1e50e32f4cfea639784 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2548844 Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Chrome Cunningham <chcunningham@chromium.org> Reviewed-by: Dan Sanders <sandersd@chromium.org> Cr-Commit-Position: refs/heads/master@{#835058}

Currently, the CheckCanStartAnimationOnCompositor is called twice for composite background-color animation, once during paint time and once during the compositing stage. The reason is that we need the decision during paint and compositing consistent. That is, if the paint stage says the background color must be paint on the main thread, then compositing stage has to agree with that, and vice versa. However, this is dangerous because between the paint and compositing stage, things could change, especially the PaintArtifactCompositor, which is used by the CheckCanStartAnimationOnCompositor. For example, it could happen that at paint time we have not produced / updated the property nodes for the current frame and we can make decision based on what was composited on the previous frame. Then at Precommit we have potentially updated / added / removed property tree nodes. In this case, the return value of CheckCanStartAnimationOnCompositor can be different, as a result, the background color animation won't run correctly. The reason we needed to know whether the animation could be composited here is that we didn't have a way to paint the background color off the main thread. More specifically, the BackgroundColorPaintWorklet::Paint() function can paint the background color only if the animation is running on the compositor thread. This CL makes following changes: 1. Make the BackgroundColorPaintWorklet::Paint() have the ability to paint the background color even if the animation is running on the main thread. The function needs two things: the current progress of the animation and the artifacts about the animation. So all we need is just getting the progress when the animation is running on the main thread. 2. With #1 being done, we no longer need to call the CheckCanStartAnimationOnCompositor during the paint step. As a result, whether or not the animation can be running on the compositor thread is solely the decision during the compositing stage. This is much safer than the current code, because we no longer need to make a compositing decision during the paint stage. We don't need to add any new tests because we already have sufficient layout tests for background color animation being run on the compositor as well as on the main thread. As long as all tests pass, this should be safe. The main benefit of this change is that the code is now more robust, meaning that we don't need to worry about the decision made by the paint and compositing stage being different. This change is also a performance win because we no longer need to call the CheckCanStartAnimationOnCompositor twice. Bug: 1185272, 1182261 Change-Id: Ie072714fd1d05e6537e05cad45ad1da99e20125b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2740697 Reviewed-by: Robert Flack <flackr@chromium.org> Commit-Queue: Xida Chen <xidachen@chromium.org> Cr-Commit-Position: refs/heads/master@{#863622}

…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. Only process ChildrenChanged() for the included root of a change. For example, if a <div id="root" style="display:none"> will be included because it is a potential relation target. If descendants change, the only ChildrenChanged() necessary to process is on #root. 2. Share common code for detaching a node and queuing up the appropriate children changes. This simplifies ProcessInvalidatedObjects() by removing one of the inner loops, and enables a follow-up CL to remove the outer loop as well. #1 results in a massive speedup for display none toggles. In combination with other recent changes in DetachAndRemoveFromChildrenOfAncestors(), is 7x faster for many-nodes-toggle-display-none in perf_tests . This change alone accounts for about half of the overall improvement. Follow-ups: - Restore lifecycle check by processing deferred children changes via nodes_with_pending_children_changed_ and not queuing via the traditional mechanism. While doing this, look for opportunities to consolidate more children changed events. - Remove outer loop from ProcessInvalidatedObjects(). Bug: None Change-Id: I80466fda792cd0ca6dd051065a42ba702e4cc8b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2946971 Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org> Cr-Commit-Position: refs/heads/master@{#891343}

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}

Relative offsets should be applied after fragmentation. Since we perform layout for OOFs once they reach the fragmentation context root (if applicable), we fail to apply any relative offsets at the correct time in the case of inline containing blocks. See CL:2851595 for how this was handled for the non-inline case. The changes required to accomplish this for inline containing blocks include: 1. We currently store an accumulated relative offset in NGContainingBlock inside the OOF node, which is any relative offset from the containing block to the fragmentation context root. We also need to store an accumulated relative offset from the inline container to the containing block in order to properly apply all relative offsets at the time of fragmentation. A new struct, NGInlineContainer, was added to the OOF node to hold the inline container object and the accumulated relative offset to the containing block. 2. A relative offset was also added to the InlineContainingBlockGeometry struct so that we have access to the relative offset from #1 when creating the ContainingBlockInfo for the inline container. 3. The way that relative offsets are applied to inlines, it didn't seem straightforward to separate the relative offset from the normal offset, like we had in CL:2851595. Instead, store the relative offset for the inline and subtract it out from the OOF static position once it reaches the containing block, and subtract it from the containing block rect offset when determining the ContainingBlockInfo for the inline container. 4. Store the total relative offset (from the inline container to the fragmentation context root) in ContainingBlockInfo. This relative offset will then be applied after fragmentation is complete for the OOF as a result of CL:2851595. Bug: 1079031 Change-Id: I7198fec4c01e05ca54c51b2f215569b75b0b869e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2995308 Commit-Queue: Alison Maher <almaher@microsoft.com> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#902060}

This patch adds a new produceCropId() API to mediaDevices. This API is called with a DIV or IFRAME element, and adds a new base::UnguessableToken value to that element's rare data structure. This token value will be used in followup patches in order to keep track of an element's location in the page and viewport. Based on the following design document: https://docs.google.com/document/d/1dULARMnMZggfWqa_Ti_GrINRNYXGIli3XK9brzAKEV8/ Bug: 1247761 Change-Id: I01cd67e2d4e3dfa7a86289f876e48c8b55095d0a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3173396 Commit-Queue: Jordan Bayles <jophba@chromium.org> Reviewed-by: Elad Alon <eladalon@chromium.org> Reviewed-by: mark a. foltz <mfoltz@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#925544}

…eVisibilityKeeper::PrepareToSplitBlockElement()` before splitting a text node It does the following things when caret is collapsed in a text node in a `<p>` or `<div>` element. 1. Split the text node containing caret to insert `<br>` element 2. Insert `<br>` element after it 3. Split ancestor elements which inclusive descendants of the `<p>` or `<div>` 4. Delete the `<br>` element if unnecessary from the left paragraph web-platform-tests#3 and web-platform-tests#4 are performed by `HTMLEditor::SplitParagraph()` and it calls `WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement()` correctly before splitting the block. However, in the case (caret is at middle of a text node), the text has already been split to 2 nodes because of #1. Therefore, it fails to handle to keep the white-space visibility. So that I believe that the root cause of this bug is, the method does much complicated things which are required, and doing the redundant things will eat memory space due to undo transactions. However, for now, I'd like to fix this with a simple patch which just call the preparation method before splitting the text node because I'd like to uplift this if it'd be approved (Note that this is not a recent regression, the root cause was created by bug 92686 which was fixed in 17 years ago: <https://searchfox.org/mozilla-central/commit/2e66280faef73e9be218e00758d4eb738395ac83>, but must be annoying bug for users who see this frequently). The new WPTs are pass in Chrome. Differential Revision: https://phabricator.services.mozilla.com/D130950 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1740416 gecko-commit: 73567f6c2bcfa078836a36760498bb11747561dd gecko-reviewers: m_kato, smaug

…rners We had two issues: 1. Before we had fast rounded corners, we always created mask layers for rounded corner clips, and the mask layer made the scroll begin unreliable and fall back to the main thread. With fast rounded corners, the scrolls were treated as reliable without checking if the point is in or out of the rounded corners. 2. If the scroller has a rounded corner by itself (instead of from an ancestor), as we only create InnerBorderRadiusClip for the contents, the compositor doesn't actually know which part of the layer bounds is transparent to hit test (e.g. if the scroller has a border which is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness, such layers have HitTestOpaqueness::kMixed. This CL changes the behavior of LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from FindLayerUpToFirstScrollableOrOpaqueToHitTest): - For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the layer is affected by any fast rounded corners; - For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only OpaqueToHitTest() (without checking IsScrollerOrScrollbar()) because a hit test on a scrollable layer is reliable only if it's opaque to hit test. Bug: 40277896 Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Steve Kobes <skobes@chromium.org> Cr-Commit-Position: refs/heads/main@{#1291538}

Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use the shadow tree of web-exposed shadow root, instead of using light DOM elements of the host. Bug #2: aRange could possibly create mCrossShadowBoundaryRange first (due to boundaries are in different tree), and later moves the boundaries to the same tree. When this happens, we should remove mCrossShadowBoundaryRange and use the default range to represent it. Differential Revision: https://phabricator.services.mozilla.com/D207608 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1891783 gecko-commit: 0f54a84c32d1c22d71ff7307944b824639adbd6f gecko-reviewers: jjaschke, smaug, dom-core

@page

Since @page border box layout objects aren't in the the layout tree, any code that wants to walk up the tree to find the containing block will be in for a surprise. This would happen if percentage-based @page padding was used [1]. Recomputing padding during painting when we have already done it during layout is rather pointless anyway. Read it out directly from the fragment. [1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent() #2 blink::LayoutBoxModelObject::ComputedCSSPadding() web-platform-tests#3 blink::LayoutBoxModelObject::PaddingTop() web-platform-tests#4 blink::LayoutBoxModelObject::PaddingOutsets() web-platform-tests#5 blink::BoxPainterBase::PaintFillLayer() web-platform-tests#6 blink::BoxPainterBase::PaintFillLayers() web-platform-tests#7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1300711}

WebRTC is one form of network communication that should be disabled when window.fence.disableUntrustedNetwork is called in a fenced frame. However, 1. We don't have any identified use cases for WebRTC in fenced frames 2. The revocation process would be more involved than other forms of network access, which would provide little benefit per #1. 3. Entirely disabling WebRTC PeerConnection instead is beneficial for privacy and does not break existing fenced frame use cases. This CL disables RTCPeerConnection construction entirely in fenced frames, regardless of whether window.fence.disableUntrustedNetwork was called or not. The change is behind an existing flag so that it does not ship until other forms of network revocation do. Disabling RTCPeerConnection *can* be handled entirely by the renderer, but a compromised renderer could potentially circumvent this to construct a peer connection anyway. A follow-up CL will add a browser-side control to ensure that this does not occur. Change-Id: Iaa2caaddeee70852179332dd89c5dbbac3ffcfbf Bug: 41488151 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5527514 Reviewed-by: Guido Urdaneta <guidou@chromium.org> Commit-Queue: Andrew Verge <averge@chromium.org> Reviewed-by: Liam Brady <lbrady@google.com> Reviewed-by: Shivani Sharma <shivanisha@chromium.org> Cr-Commit-Position: refs/heads/main@{#1319162}

Update tests for DAP ambient light events

760cc8b

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

Merge pull request #1 from pjckcs/dap-light

00333c5

Update tests for DAP ambient light events

dontcallmedom merged commit 00333c5 into dontcallmedom:dap-light Sep 23, 2013

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

Merge pull request #1 from finnle/patch-1

7c1fde3

Update storagesize1html.html

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

Merge pull request #1 from foolip/submission/Opera/media

fcb1878

Fix a few review issues

dontcallmedom pushed a commit that referenced this pull request Jun 16, 2015

Merge pull request #1 from dontcallmedom/webrtc-datachannel-empty

619da23

focus test only on empty string exchange

dontcallmedom pushed a commit that referenced this pull request Mar 22, 2017

Merge pull request web-platform-tests#4629 from w3c/chromium-export-try

15f055e

Revert of Create a change in external/wpt meant to be reverted (patchset #1 id:1 of https://codereview.chromium.org/2651533003/ )

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Update tests for DAP ambient light events #1

Update tests for DAP ambient light events #1

Uh oh!

zqzhang commented Sep 22, 2013

Uh oh!

Uh oh!

Update tests for DAP ambient light events #1

Update tests for DAP ambient light events #1

Uh oh!

Conversation

zqzhang commented Sep 22, 2013

Uh oh!

Uh oh!