Comcast's submission #4

darobin · 2012-12-20T15:27:31Z

No description provided.

Ms2ger · 2012-12-22T16:18:05Z

There are a number of tests for document.title already; I don't think this adds anything.

Update format-field-data.htm

Delete storagesize8xmlrules.xml

Update

…fect Upstream element-animate-null-effect.html from Blink

w3c-bots · 2017-02-03T14:29:58Z

Chrome (unstable channel)

Testing web-platform-tests at revision c348bd8
Using browser at version 57.0.2987.19 dev
Starting 10 test iterations
All results were stable

All results

/dom/collections/HTMLCollection-empty-name.html

Subtest	Results
	OK
`Empty string as a name for Document.getElementsByClassName`	PASS
`Empty string as a name for Document.getElementsByTagName`	PASS
`Empty string as a name for Element.children`	PASS
`Empty string as a name for Element.getElementsByTagNameNS`	PASS
`Empty string as a name for Document.getElementsByTagNameNS`	PASS
`Empty string as a name for Element.getElementsByClassName`	PASS
`Empty string as a name for Element.getElementsByTagName`	PASS

w3c-bots · 2017-02-03T14:29:58Z

Firefox (nightly channel)

Testing web-platform-tests at revision c348bd8
Using browser at version BuildID 20170123125947; SourceStamp 36486fdc3813ef7943ae5b07b4128866d1938a6c
Starting 10 test iterations
All results were stable

All results

/dom/collections/HTMLCollection-empty-name.html

Subtest	Results
	OK
`Empty string as a name for Document.getElementsByClassName`	PASS
`Empty string as a name for Document.getElementsByTagName`	PASS
`Empty string as a name for Element.children`	PASS
`Empty string as a name for Element.getElementsByTagNameNS`	PASS
`Empty string as a name for Document.getElementsByTagNameNS`	PASS
`Empty string as a name for Element.getElementsByClassName`	PASS
`Empty string as a name for Element.getElementsByTagName`	PASS

w3c-bots · 2017-02-03T14:29:59Z

Firefox (nightly channel)

Testing web-platform-tests at revision c348bd8
Using browser at version BuildID 20170123125947; SourceStamp 36486fdc3813ef7943ae5b07b4128866d1938a6c
Starting 10 test iterations
All results were stable

All results

/dom/collections/HTMLCollection-empty-name.html

Subtest	Results
	OK
`Empty string as a name for Document.getElementsByClassName`	PASS
`Empty string as a name for Document.getElementsByTagName`	PASS
`Empty string as a name for Element.children`	PASS
`Empty string as a name for Element.getElementsByTagNameNS`	PASS
`Empty string as a name for Document.getElementsByTagNameNS`	PASS
`Empty string as a name for Element.getElementsByClassName`	PASS
`Empty string as a name for Element.getElementsByTagName`	PASS

bobholt · 2017-02-03T14:38:16Z

Sorry for the w3c-bots comment noise. I could explain how that happened, but it wouldn't be interesting.

Fix a reference to Request.path, which doesn't exist.

Look for the lint whitelist in the repo root; r=Ms2ger

Correct requests issued for window-related commands

…mPoint" This reverts commit dd944882a245a5117b50cb417138d92f32d931d6. Reason for revert: This causes WebKit Linux Trusty ASAN buildbot failure. https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20ASAN/builds/8618 23:46:29.565 3877 ==1==ERROR: AddressSanitizer: use-after-poison on address 0x7ead60c0dbf0 at pc 0x00000dca937a bp 0x7ffd86b90c10 sp 0x7ffd86b90c08 23:46:29.565 3877 READ of size 8 at 0x7ead60c0dbf0 thread T0 (content_shell) 23:46:29.565 3877 #0 0xdca9379 in operator==<const blink::TreeScope, const blink::TreeScope> third_party/WebKit/Source/platform/heap/Member.h:128:27 23:46:29.565 3877 #1 0xdca9379 in blink::TreeScope::Retarget(blink::Element const&) const third_party/WebKit/Source/core/dom/TreeScope.cpp:393:0 23:46:29.565 3877 #2 0xdca8894 in blink::TreeScope::HitTestPointInternal(blink::Node*) const third_party/WebKit/Source/core/dom/TreeScope.cpp:267:10 23:46:29.565 3877 #3 0xdca8325 in HitTestPoint third_party/WebKit/Source/core/dom/TreeScope.cpp:254:10 23:46:29.566 3877 #4 0xdca8325 in blink::TreeScope::ElementFromPoint(double, double) const third_party/WebKit/Source/core/dom/TreeScope.cpp:245:0 23:46:29.566 3877 #5 0xc9353a7 in elementFromPoint third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:38:23 Original change's description: > Fix retargeting of result in elementFromPoint and elementsFromPoint > > Currently elementFromPoint and elementsFromPoint are not per spec, and it may > return null incorrectly. This change adds retargeting of the result with > respect to the context object, and adds some tests that are similar to > elementFromPoint tests in WebKit, but with some corrected cases: > https://git.webkit.org/?p=WebKit-https.git;a=blob;f=LayoutTests/fast/shadow-dom/DocumentOrShadowRoot-prototype-elementFromPoint.html;h=a8dc4da2430713521b9ba77c742db10397a8e638;hb=HEAD > > Spec: > https://w3c.github.io/webcomponents/spec/shadow/#extensions-to-the-documentorshadowroot-mixin > > Bug: 759947 > Change-Id: I6aece5e9cc826124772c6ce13c806865055b2b9b > Reviewed-on: https://chromium-review.googlesource.com/808446 > Commit-Queue: Rakina Zata Amni <[email protected]> > Reviewed-by: Dmitry Gozman <[email protected]> > Reviewed-by: Hayato Ito <[email protected]> > Reviewed-by: Takayoshi Kochi <[email protected]> > Cr-Commit-Position: refs/heads/master@{#531139} [email protected],[email protected],[email protected],[email protected],[email protected] Change-Id: Id62abd371d93627d3178b63ca189cecfe9ff44d4 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 759947 Reviewed-on: https://chromium-review.googlesource.com/880264 Reviewed-by: Takashi Sakamoto <[email protected]> Commit-Queue: Takashi Sakamoto <[email protected]> Cr-Commit-Position: refs/heads/master@{#531178}

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> #14 0x563ff39ff32b <unknown> #15 0x563ff39ff70c <unknown> #16 0x563ff39d940a <unknown> #17 0x563ff39ff997 <unknown> #18 0x563ff39e9947 <unknown> #19 0x563ff3a1a800 <unknown> #20 0x563ff3a3c8be <unknown> #21 0x7f3bf4545494 start_thread #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

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}

Flow relative longhands have been added to overscroll-behavior. [1] TODO: This is not yet functional as I think we need to teach css parser to map inline/block to their physical counterparts x/y. Something similar to direction_aware_properties [2] but only on the axes. There may be other simpler way to do this. Currently this crashes in [3]. [1] https://drafts.csswg.org/css-overscroll-behavior-1/#overscroll-behavior-longhands-logical [2] https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/css/css_properties.json5?q=css_properties.json5&sq=package:chromium&dr&l=332 [3] Current crash: STDERR: [1:1:0516/112659.776302:FATAL:css_property_parser_helpers.cc(1928)] Check failed: shorthand.length() == 2u (4 vs. 2) STDERR: #0 0x7f40c88436b1 base::debug::CollectStackTrace() STDERR: #1 0x7f40c8593bfd base::debug::StackTrace::StackTrace() STDERR: #2 0x7f40c8593bb8 base::debug::StackTrace::StackTrace() STDERR: #3 0x7f40c85e2829 logging::LogMessage::~LogMessage() STDERR: #4 0x7f40b025e6bd blink::css_property_parser_helpers::ConsumeShorthandVia2Longhands() STDERR: #5 0x7f40b0331909 blink::css_shorthand::OverscrollBehavior::ParseShorthand() STDERR: #6 0x7f40b025782a blink::CSSPropertyParser::ParseValueStart() STDERR: #7 0x7f40b0256e35 blink::CSSPropertyParser::ParseValue() STDERR: #8 0x7f40b02456ec blink::CSSParserImpl::ConsumeDeclarationValue() STDERR: #9 0x7f40b02455be blink::CSSParserImpl::ParseValue() STDERR: #10 0x7f40b023956a blink::CSSParser::ParseValue() STDERR: #11 0x7f40b02394f4 blink::CSSParser::ParseValue() STDERR: #12 0x7f40b00ef77f blink::MutableCSSPropertyValueSet::SetProperty() STDERR: #13 0x7f40b004c5a9 blink::AbstractPropertySetCSSStyleDeclaration::SetPropertyInternal() Change-Id: I5ceefa0afb1913472c0e134b2ec07405154abfae

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> #14 0x563ff39ff32b <unknown> #15 0x563ff39ff70c <unknown> #16 0x563ff39d940a <unknown> #17 0x563ff39ff997 <unknown> #18 0x563ff39e9947 <unknown> #19 0x563ff3a1a800 <unknown> #20 0x563ff3a3c8be <unknown> #21 0x7f3bf4545494 start_thread #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

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}

…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

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

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

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}

See [1] for more context, but this CL makes the following changes to the declarative Shadow DOM getInnerHTML API: 1. Rename getInnerHTML to getComposedInnerHTML 2. Rename includeShadowRoots to includeOpenShadowRoots 3. Rename closedRoots to shadowRoots 4. Change behavior so that the options are more independent, and either can be used without the other. Mostly, the above is a rename operation, with the exception of #4. There, the logic change is relatively minor, mostly happening in markup_accumulator.cc around line 564. Note: this also fixes the MeasureAs vs. RuntimeCallStats. [1] mfreed7/declarative-shadow-dom#9 (comment) Bug: 1042130 Change-Id: Ie4a0b18a2ef28f17b97eca33c018f7479fc20de8

See [1] for more context, but this CL makes the following changes to the declarative Shadow DOM getInnerHTML API: 1. Rename getInnerHTML to getComposedInnerHTML 2. Rename includeShadowRoots to includeOpenShadowRoots 3. Rename closedRoots to shadowRoots 4. Change behavior so that the options are more independent, and either can be used without the other. Mostly, the above is a rename operation, with the exception of #4. There, the logic change is relatively minor, mostly happening in markup_accumulator.cc around line 564. Note: this also fixes the MeasureAs vs. RuntimeCallStats. [1] mfreed7/declarative-shadow-dom#9 (comment) Bug: 1042130 Change-Id: Ie4a0b18a2ef28f17b97eca33c018f7479fc20de8 Cq-Do-Not-Cancel-Tryjobs: true

…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 #3 and #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

…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 web-platform-tests#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

This CL improves the testing of template cloning with Parts, testing these four cases: 1. Main document parsing 2. Template (content fragment) parsing 3. Template/fragment cloning 4. Declarative Shadow DOM parsing and cloning This CL fixes the behavior for #3 above, but leaves #4 broken. The following changes in behavior are made: 1. Part::MoveToRoot() can be used to change the root(), including to set it to nullptr. This happens when a Node tree is removed from the DOM, and it contains Parts that refer to the old root. 2. IsDocumentPartRoot() is now virtual, because during a tree move, the root() for a Part can be made nullptr even when it's a ChildNodePart. 3. Part::disconnected_ is added to keep track of whether the Part has been disconnected, since root() can now be nullptr. 4. (This is a bug fix) When using ChildNodePart::setNextSibling(), the new sibling node wasn't having its Part registered with NodeRareData, which caused a CHECK failure when trying to subsequently clone that Part. This is caught in the new test which clones declaratively-built templates containing Parts. Bug: 1453291 Change-Id: Ic1c1475431cf6bd658f191db78003204412ef78f

This CL improves the testing of template cloning with Parts, testing these four cases: 1. Main document parsing 2. Template (content fragment) parsing 3. Template/fragment cloning 4. Declarative Shadow DOM parsing and cloning This CL fixes the behavior for #3 above, but leaves #4 broken. The following changes in behavior are made: 1. Part::MoveToRoot() can be used to change the root(), including to set it to nullptr. This happens when a Node tree is removed from the DOM, and it contains Parts that refer to the old root. 2. IsDocumentPartRoot() is now virtual, because during a tree move, the root() for a Part can be made nullptr even when it's a ChildNodePart. 3. Part::disconnected_ is added to keep track of whether the Part has been disconnected, since root() can now be nullptr. 4. (This is a bug fix) When using ChildNodePart::setNextSibling(), the new sibling node wasn't having its Part registered with NodeRareData, which caused a CHECK failure when trying to subsequently clone that Part. This is caught in the new test which clones declaratively-built templates containing Parts. Bug: 1453291 Change-Id: Ic1c1475431cf6bd658f191db78003204412ef78f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4713668 Reviewed-by: David Baron <[email protected]> Auto-Submit: Mason Freed <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1175782}

This CL improves the testing of template cloning with Parts, testing these four cases: 1. Main document parsing 2. Template (content fragment) parsing 3. Template/fragment cloning 4. Declarative Shadow DOM parsing and cloning This CL fixes the behavior for web-platform-tests#3 above, but leaves web-platform-tests#4 broken. The following changes in behavior are made: 1. Part::MoveToRoot() can be used to change the root(), including to set it to nullptr. This happens when a Node tree is removed from the DOM, and it contains Parts that refer to the old root. 2. IsDocumentPartRoot() is now virtual, because during a tree move, the root() for a Part can be made nullptr even when it's a ChildNodePart. 3. Part::disconnected_ is added to keep track of whether the Part has been disconnected, since root() can now be nullptr. 4. (This is a bug fix) When using ChildNodePart::setNextSibling(), the new sibling node wasn't having its Part registered with NodeRareData, which caused a CHECK failure when trying to subsequently clone that Part. This is caught in the new test which clones declaratively-built templates containing Parts. Bug: 1453291 Change-Id: Ic1c1475431cf6bd658f191db78003204412ef78f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4713668 Reviewed-by: David Baron <[email protected]> Auto-Submit: Mason Freed <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1175782}

@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() #3 blink::LayoutBoxModelObject::PaddingTop() #4 blink::LayoutBoxModelObject::PaddingOutsets() #5 blink::BoxPainterBase::PaintFillLayer() #6 blink::BoxPainterBase::PaintFillLayers() #7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102

@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() #3 blink::LayoutBoxModelObject::PaddingTop() #4 blink::LayoutBoxModelObject::PaddingOutsets() #5 blink::BoxPainterBase::PaintFillLayer() #6 blink::BoxPainterBase::PaintFillLayers() #7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469 Commit-Queue: Morten Stenshorne <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1300711}

@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() #3 blink::LayoutBoxModelObject::PaddingTop() #4 blink::LayoutBoxModelObject::PaddingOutsets() #5 blink::BoxPainterBase::PaintFillLayer() #6 blink::BoxPainterBase::PaintFillLayers() #7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469 Commit-Queue: Morten Stenshorne <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1300711}

Comcast's submission

f30bebe

Ms2ger closed this Dec 22, 2012

odinho added a commit that referenced this pull request Apr 4, 2013

Merge pull request #4 from Yaffle/patch-3

a490f31

Update format-field-data.htm

fsasaki added a commit that referenced this pull request Sep 25, 2013

Merge pull request #4 from finnle/patch-4

9e21119

Delete storagesize8xmlrules.xml

AFBarstow mentioned this pull request Sep 30, 2013

WebIDL tests #271

Open

sideshowbarker deleted the submission/Comcast branch June 18, 2015 07:23

jimsch pushed a commit that referenced this pull request Jul 6, 2016

Merge pull request #4 from w3c/master

9645ea5

Update

alancutter pushed a commit to alancutter/web-platform-tests that referenced this pull request Jul 15, 2016

Merge pull request web-platform-tests#4 from alancutter/animateNullEf…

26605e3

…fect Upstream element-animate-null-effect.html from Blink

jgraham added a commit that referenced this pull request Apr 13, 2017

Merge pull request #4 from Ms2ger/fix-request-repr

7b6c5fd

Fix a reference to Request.path, which doesn't exist.

jgraham pushed a commit that referenced this pull request Apr 13, 2017

Merge pull request #4 from w3c/jgraham/move_lint_whitelist

09e9f21

Look for the lint whitelist in the repo root; r=Ms2ger

jgraham pushed a commit that referenced this pull request Apr 13, 2017

Merge pull request #4 from jugglinmike/window-commands

efbdbb1

Correct requests issued for window-related commands

chromium-wpt-export-bot mentioned this pull request Jan 23, 2018

Revert "Fix retargeting of result in elementFromPoint and elementsFromPoint" #9132

Merged

chromium-wpt-export-bot mentioned this pull request May 8, 2019

Revert "Correctly handle scroll-snap-type changes to 'none'" #16724

Merged

chromium-wpt-export-bot mentioned this pull request May 16, 2019

Add support for overscroll-behavior logical longhands #16890

Merged

chromium-wpt-export-bot mentioned this pull request Jan 21, 2021

wpt computing-row-measure-0.html fix #27265

Merged

WeizhongX mentioned this pull request Feb 23, 2021

WebDriverException exception is not properly captured #27751

Closed

chromium-wpt-export-bot mentioned this pull request Mar 30, 2021

Make changes to declarative Shadow DOM getInnerHTML API #28306

Closed

moz-wptsync-bot mentioned this pull request Nov 12, 2021

[Gecko Bug 1740416] Make HTMLEditor::HandleInsertParagraphInParagraph() call WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement() before splitting a text node #31624

Merged

chromium-wpt-export-bot mentioned this pull request Jul 25, 2023

Fix cloning of templates with DOM Parts, and improve testing #41168

Merged

bkardell mentioned this pull request Nov 28, 2023

Add tests for ::first-letter and ::first-line with MathML #43334

Merged

chromium-wpt-export-bot mentioned this pull request May 14, 2024

Get border/padding from fragment when painting background. #46252

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comcast's submission #4

Comcast's submission #4

darobin commented Dec 20, 2012

Ms2ger commented Dec 22, 2012

w3c-bots commented Feb 3, 2017

w3c-bots commented Feb 3, 2017

w3c-bots commented Feb 3, 2017

bobholt commented Feb 3, 2017

Comcast's submission #4

Comcast's submission #4

Conversation

darobin commented Dec 20, 2012

Ms2ger commented Dec 22, 2012

w3c-bots commented Feb 3, 2017

Chrome (unstable channel)

All results

w3c-bots commented Feb 3, 2017

Firefox (nightly channel)

All results

w3c-bots commented Feb 3, 2017

Firefox (nightly channel)

All results

bobholt commented Feb 3, 2017