Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

David Carlisle's submission #5

Closed
wants to merge 1 commit into from
Closed

Conversation

darobin
Copy link
Contributor

@darobin darobin commented Dec 20, 2012

No description provided.

@Ms2ger
Copy link
Contributor

Ms2ger commented Dec 22, 2012

math-parse01.html already is in the repo, in a better place (syntax/parsing); and math-parse02.html and math-render01.html don't test anything in the HTML spec.

@Ms2ger Ms2ger closed this Dec 22, 2012
odinho added a commit that referenced this pull request Apr 4, 2013
Update format-comments.htm with newline on last event (4)
@sideshowbarker sideshowbarker deleted the submission/DavidCarlisle branch June 18, 2015 07:23
@mikewest mikewest mentioned this pull request Jul 1, 2015
jimsch pushed a commit that referenced this pull request Jul 6, 2016
Catch up to W3C master
alancutter pushed a commit to alancutter/web-platform-tests that referenced this pull request Jul 15, 2016
…ish-events

Upstream updating-the-finished-state.html from Blink
jeffcarp pushed a commit that referenced this pull request Mar 23, 2017
… (patchset #5 id:80001 of https://codereview.chromium.org/2723433002/ )

Reason for revert:
Temporarily reverting this CL because it causes a perf regression. See http://crbug.com/703605.

Will reland once we understand why the regression occurred.

Original issue's description:
> Remove |remote| and |readonly| members of MediaStreamTrack.
>
> Spec reference:
> http://w3c.github.io/mediacapture-main/getusermedia.html#attributes-1
>
> removal was in the February 22, 2016'.
> [#321] Remove track attributes "remote" and "readonly" :
> w3c/mediacapture-main#321
>
> Intent to Deprecate and Remove :
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/d20ECb2sWzI
>
> BUG=598704
>
> Review-Url: https://codereview.chromium.org/2723433002
> Cr-Commit-Position: refs/heads/master@{#456639}
> Committed: https://chromium.googlesource.com/chromium/src/+/27c39dbef0b07b7cd62fb2476d0f0836115fe672

TBR=tkent@chromium.org,aelias@chromium.org,alexmos@chromium.org,bbudge@chromium.org,dpranke@chromium.org,drott@chromium.org,esprehn@chromium.org,haraken@chromium.org,hongchan@chromium.org,hta@chromium.org,mcasas@chromium.org,mkwst@chromium.org,peter@chromium.org,rdevlin.cronin@chromium.org,sergeyu@chromium.org,peary2@gmail.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=598704

Review-Url: https://codereview.chromium.org/2767963002
Cr-Commit-Position: refs/heads/master@{#459096}
chromium-wpt-export-bot added a commit that referenced this pull request Mar 23, 2017
Revert of Remove |remote| and |readonly| members of MediaStreamTrack. (patchset #5 id:80001 of https://codereview.chromium.org/2723433002/ )
jeffcarp added a commit that referenced this pull request Mar 24, 2017
Revert "Revert of Remove |remote| and |readonly| members of MediaStreamTrack. (patchset #5 id:80001 of https://codereview.chromium.org/2723433002/ )"
jgraham added a commit that referenced this pull request Apr 13, 2017
Include README.md for source distribution
jgraham added a commit that referenced this pull request Apr 13, 2017
chromium-wpt-export-bot pushed a commit that referenced this pull request May 17, 2017
…ullptr when entry not found / "fetching" (patchset #5 id:80001 of https://codereview.chromium.org/2860993002/ )

Reason for revert:
This CL probably causes test failures
 external/wpt/html/semantics/scripting-1/the-script-element/module/import-subgraph-404.html

The first failed build:
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20Leak/builds/4742

Original issue's description:
> [ES6 modules] ModuleMap::GetFetchedModuleScript to return nullptr when entry not found / "fetching"
>
> Before this CL, we asserted that ModuleMap::GetFetchedModuleScript always queried load completed module scripts, but it was not always the case.
> This CL changes the member function to return nullptr if the entry doesn't exist or the entry is being fetched.
>
> This CL fixes a crash that happens when we early-exit module script graph fetch by a sub-graph instantiation failed, but there are still partial subgraph in flight.
>
> BUG=718442,594639
>
> Review-Url: https://codereview.chromium.org/2860993002
> Cr-Commit-Position: refs/heads/master@{#472192}
> Committed: https://chromium.googlesource.com/chromium/src/+/1f92cfbdedaecb97e8a87773deb32f98c6997351

TBR=domenic@chromium.org,module-dev@chromium.org,neis@chromium.org,hiroshige@chromium.org,kouhei@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=718442,594639

Review-Url: https://codereview.chromium.org/2886123002
Cr-Commit-Position: refs/heads/master@{#472402}
chromium-wpt-export-bot pushed a commit that referenced this pull request May 17, 2017
…ullptr when entry not found / "fetching" (patchset #5 id:80001 of https://codereview.chromium.org/2860993002/ )

Reason for revert:
This CL probably causes test failures
 external/wpt/html/semantics/scripting-1/the-script-element/module/import-subgraph-404.html

The first failed build:
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20Leak/builds/4742

Original issue's description:
> [ES6 modules] ModuleMap::GetFetchedModuleScript to return nullptr when entry not found / "fetching"
>
> Before this CL, we asserted that ModuleMap::GetFetchedModuleScript always queried load completed module scripts, but it was not always the case.
> This CL changes the member function to return nullptr if the entry doesn't exist or the entry is being fetched.
>
> This CL fixes a crash that happens when we early-exit module script graph fetch by a sub-graph instantiation failed, but there are still partial subgraph in flight.
>
> BUG=718442,594639
>
> Review-Url: https://codereview.chromium.org/2860993002
> Cr-Commit-Position: refs/heads/master@{#472192}
> Committed: https://chromium.googlesource.com/chromium/src/+/1f92cfbdedaecb97e8a87773deb32f98c6997351

TBR=domenic@chromium.org,module-dev@chromium.org,neis@chromium.org,hiroshige@chromium.org,kouhei@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=718442,594639

Review-Url: https://codereview.chromium.org/2886123002
Cr-Commit-Position: refs/heads/master@{#472402}
chromium-wpt-export-bot pushed a commit that referenced this pull request May 22, 2017
…ullptr when entry not found / "fetching" (patchset #5 id:80001 of https://codereview.chromium.org/2860993002/ )

Reason for revert:
This CL probably causes test failures
 external/wpt/html/semantics/scripting-1/the-script-element/module/import-subgraph-404.html

The first failed build:
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20Leak/builds/4742

Original issue's description:
> [ES6 modules] ModuleMap::GetFetchedModuleScript to return nullptr when entry not found / "fetching"
>
> Before this CL, we asserted that ModuleMap::GetFetchedModuleScript always queried load completed module scripts, but it was not always the case.
> This CL changes the member function to return nullptr if the entry doesn't exist or the entry is being fetched.
>
> This CL fixes a crash that happens when we early-exit module script graph fetch by a sub-graph instantiation failed, but there are still partial subgraph in flight.
>
> BUG=718442,594639
>
> Review-Url: https://codereview.chromium.org/2860993002
> Cr-Commit-Position: refs/heads/master@{#472192}
> Committed: https://chromium.googlesource.com/chromium/src/+/1f92cfbdedaecb97e8a87773deb32f98c6997351

TBR=domenic@chromium.org,module-dev@chromium.org,neis@chromium.org,hiroshige@chromium.org,kouhei@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=718442,594639

Review-Url: https://codereview.chromium.org/2886123002
Cr-Commit-Position: refs/heads/master@{#472402}
chromium-wpt-export-bot pushed a commit that referenced this pull request May 22, 2017
…ullptr when entry not found / "fetching" (patchset #5 id:80001 of https://codereview.chromium.org/2860993002/ )

Reason for revert:
This CL probably causes test failures
 external/wpt/html/semantics/scripting-1/the-script-element/module/import-subgraph-404.html

The first failed build:
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20Leak/builds/4742

Original issue's description:
> [ES6 modules] ModuleMap::GetFetchedModuleScript to return nullptr when entry not found / "fetching"
>
> Before this CL, we asserted that ModuleMap::GetFetchedModuleScript always queried load completed module scripts, but it was not always the case.
> This CL changes the member function to return nullptr if the entry doesn't exist or the entry is being fetched.
>
> This CL fixes a crash that happens when we early-exit module script graph fetch by a sub-graph instantiation failed, but there are still partial subgraph in flight.
>
> BUG=718442,594639
>
> Review-Url: https://codereview.chromium.org/2860993002
> Cr-Commit-Position: refs/heads/master@{#472192}
> Committed: https://chromium.googlesource.com/chromium/src/+/1f92cfbdedaecb97e8a87773deb32f98c6997351

TBR=domenic@chromium.org,module-dev@chromium.org,neis@chromium.org,hiroshige@chromium.org,kouhei@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=718442,594639

Review-Url: https://codereview.chromium.org/2886123002
Cr-Commit-Position: refs/heads/master@{#472402}
AutomatedTester referenced this pull request in AutomatedTester/web-platform-tests Dec 1, 2017
@ghost
Copy link

ghost commented Dec 19, 2017

Build PENDING

Started: None
Finished: None

View more information about this build on:

chromium-wpt-export-bot pushed a commit that referenced this pull request Jan 23, 2018
…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 <rakina@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Reviewed-by: Hayato Ito <hayato@chromium.org>
> Reviewed-by: Takayoshi Kochi <kochi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#531139}

TBR=kochi@chromium.org,dgozman@chromium.org,hayato@chromium.org,pfeldman@chromium.org,rakina@chromium.org

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 <tasak@google.com>
Commit-Queue: Takashi Sakamoto <tasak@google.com>
Cr-Commit-Position: refs/heads/master@{#531178}
chromium-wpt-export-bot pushed a commit that referenced this pull request Jan 23, 2018
…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 <rakina@chromium.org>
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Reviewed-by: Hayato Ito <hayato@chromium.org>
> Reviewed-by: Takayoshi Kochi <kochi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#531139}

TBR=kochi@chromium.org,dgozman@chromium.org,hayato@chromium.org,pfeldman@chromium.org,rakina@chromium.org

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 <tasak@google.com>
Commit-Queue: Takashi Sakamoto <tasak@google.com>
Cr-Commit-Position: refs/heads/master@{#531178}
chromium-wpt-export-bot pushed a commit that referenced this pull request Mar 2, 2019
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
Hexcles pushed a commit that referenced this pull request Mar 5, 2019
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
Hexcles pushed a commit that referenced this pull request Mar 6, 2019
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
chromium-wpt-export-bot pushed a commit that referenced this pull request May 16, 2019
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
chromium-wpt-export-bot pushed a commit that referenced this pull request Jun 14, 2019
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
marcoscaceres pushed a commit that referenced this pull request Jul 23, 2019
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
chromium-wpt-export-bot pushed a commit that referenced this pull request Nov 6, 2019
…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
chromium-wpt-export-bot pushed a commit that referenced this pull request Nov 6, 2019
…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
chromium-wpt-export-bot pushed a commit that referenced this pull request Nov 7, 2019
…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 <dgrogan@chromium.org>
Auto-Submit: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#713296}
chromium-wpt-export-bot pushed a commit that referenced this pull request Nov 7, 2019
…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 <dgrogan@chromium.org>
Auto-Submit: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#713296}
chromium-wpt-export-bot pushed a commit that referenced this pull request Feb 27, 2020
Patch #5: On desktop, pass currency to the CanMakePaymentEvent when
minimal UI feature is enabled, so the updated WPTs can pass.

Before this patch, the "currency" field of the CanMakePaymentEvent was
never set.

After this patch, the "currency" field of the CanMakePaymentEvent is set
on desktop when the minimal UI feature is enabled, e.g., through
chrome://flags/#enable-web-payments-minimal-ui flag, and the updated WPT
passes on desktop when opened in a full browser.

Bug: 1005076
Change-Id: Ib35ef8f808f57d7674a5712f12fbfe65918ce92a
chromium-wpt-export-bot pushed a commit that referenced this pull request Feb 28, 2020
Patch #5: On desktop, pass currency to the CanMakePaymentEvent when
minimal UI feature is enabled, so the updated WPTs can pass.

Before this patch, the "currency" field of the CanMakePaymentEvent was
never set.

After this patch, the "currency" field of the CanMakePaymentEvent is set
on desktop when the minimal UI feature is enabled, e.g., through
chrome://flags/#enable-web-payments-minimal-ui flag, and the updated WPT
passes on desktop when opened in a full browser.

Bug: 1005076
Change-Id: Ib35ef8f808f57d7674a5712f12fbfe65918ce92a
chromium-wpt-export-bot pushed a commit that referenced this pull request Mar 2, 2020
Patch #5: On desktop, pass currency to the CanMakePaymentEvent when
minimal UI feature is enabled, so the updated WPTs can pass.

Before this patch, the "currency" field of the CanMakePaymentEvent was
never set.

After this patch, the "currency" field of the CanMakePaymentEvent is set
on desktop when the minimal UI feature is enabled, e.g., through
chrome://flags/#enable-web-payments-minimal-ui flag, and the updated WPT
passes on desktop when opened in a full browser.

Bug: 1005076
Change-Id: Ib35ef8f808f57d7674a5712f12fbfe65918ce92a
chromium-wpt-export-bot pushed a commit that referenced this pull request Mar 2, 2020
Patch #5: On desktop, pass currency to the CanMakePaymentEvent when
minimal UI feature is enabled, so the updated WPTs can pass.

Before this patch, the "currency" field of the CanMakePaymentEvent was
never set.

After this patch, the "currency" field of the CanMakePaymentEvent is set
on desktop when the minimal UI feature is enabled, e.g., through
chrome://flags/#enable-web-payments-minimal-ui flag, and the updated WPT
passes on desktop when opened in a full browser.

Bug: 1005076
Change-Id: Ib35ef8f808f57d7674a5712f12fbfe65918ce92a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2078797
Reviewed-by: Danyao Wang <danyao@chromium.org>
Commit-Queue: Rouslan Solomakhin <rouslan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#745955}
chromium-wpt-export-bot pushed a commit that referenced this pull request Mar 2, 2020
Patch #5: On desktop, pass currency to the CanMakePaymentEvent when
minimal UI feature is enabled, so the updated WPTs can pass.

Before this patch, the "currency" field of the CanMakePaymentEvent was
never set.

After this patch, the "currency" field of the CanMakePaymentEvent is set
on desktop when the minimal UI feature is enabled, e.g., through
chrome://flags/#enable-web-payments-minimal-ui flag, and the updated WPT
passes on desktop when opened in a full browser.

Bug: 1005076
Change-Id: Ib35ef8f808f57d7674a5712f12fbfe65918ce92a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2078797
Reviewed-by: Danyao Wang <danyao@chromium.org>
Commit-Queue: Rouslan Solomakhin <rouslan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#745955}
chromium-wpt-export-bot pushed a commit that referenced this pull request Sep 7, 2020
use of test-only-api.js in preparation for launching official MojoJS support
in WPT. This would not change the test results on Chromium waterfall
(everything should continue to pass) or upstream WPT (tests currently
fail because MojoJS isn't enabled).

TEST #5 ('The Contact API correctly returns ContactInfo entries')
TIMES OUT after this this change.

Bug: 1123989
Change-Id: Ib7fed092b37243b82fbbf38d871bb75728cb7744
chromium-wpt-export-bot pushed a commit that referenced this pull request May 14, 2024
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
chromium-wpt-export-bot pushed a commit that referenced this pull request May 14, 2024
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 <mstensho@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1300711}
chromium-wpt-export-bot pushed a commit that referenced this pull request May 14, 2024
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 <mstensho@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1300711}
spectranaut pushed a commit that referenced this pull request Jul 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants