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

Revamp how fieldset and legend rendering is defined #3934

Merged
merged 50 commits into from Sep 19, 2018

Conversation

@zcorpan
Member

zcorpan commented Aug 17, 2018

Properly define the rendering of the fieldset and legend elements.

The layout model used is most similar to Gecko, which uses an anonymous box to hold the fieldset's contents.

Fixes #3955, fixes #3930, fixes #3929, fixes #3928, fixes #3927, fixes #3915, fixes #3913, fixes #3660, fixes #3331, fixes #2756, fixes #4013.

Layout model of fieldset


/infrastructure.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/references.html ( diff )
/rendering.html ( diff )

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan
Member

zcorpan commented Aug 17, 2018

Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Aug 21, 2018

Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Aug 21, 2018

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Aug 21, 2018

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Aug 21, 2018

@mstensho

This comment has been minimized.

Show comment
Hide comment
@mstensho

mstensho Aug 21, 2018

Containing block size calculation (for e.g. percentage height resolution) for legends needs to be specced. I imagine it should contain the logical top border and padding areas (since legends are placed above the padding area, and are part of the border), although no browsers do that currently:

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6133 (only testing borders, no padding)

mstensho commented Aug 21, 2018

Containing block size calculation (for e.g. percentage height resolution) for legends needs to be specced. I imagine it should contain the logical top border and padding areas (since legends are placed above the padding area, and are part of the border), although no browsers do that currently:

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6133 (only testing borders, no padding)

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Aug 21, 2018

Edge/Firefox/Chrome renders the percentage height testcase the same though, so I think we should spec that rather than risk regressing existing web content. Also, I don't consider a rendered legend to be "part of the border" because then its extent should be part of the border-box area and thus the fieldset background should render behind it (fully), a box-shadow should wrap it etc, and that's not what any UAs do as far as I know.

Perhaps the spec would benefit from an example figure that visualizes the rendering? Something like this table figure. In Gecko we implement the <fieldset> using two boxes, an outer box that contains the rendered legend as the first child box and an inner anonymous box that contains the boxes of the other <fieldset> children. (Similar to how the table wrapper box wraps its caption and an inner table box.) Then it would be easier to discuss where and how the margin/padding/border of the various boxes should be applied and how a "reserved space" for the rendered legend should be calculated.

MatsPalmgren commented Aug 21, 2018

Edge/Firefox/Chrome renders the percentage height testcase the same though, so I think we should spec that rather than risk regressing existing web content. Also, I don't consider a rendered legend to be "part of the border" because then its extent should be part of the border-box area and thus the fieldset background should render behind it (fully), a box-shadow should wrap it etc, and that's not what any UAs do as far as I know.

Perhaps the spec would benefit from an example figure that visualizes the rendering? Something like this table figure. In Gecko we implement the <fieldset> using two boxes, an outer box that contains the rendered legend as the first child box and an inner anonymous box that contains the boxes of the other <fieldset> children. (Similar to how the table wrapper box wraps its caption and an inner table box.) Then it would be easier to discuss where and how the margin/padding/border of the various boxes should be applied and how a "reserved space" for the rendered legend should be calculated.

@mstensho

This comment has been minimized.

Show comment
Hide comment
@mstensho

mstensho Aug 21, 2018

Yes, all browsers render the same with my test, and I do agree that it's risky to spec it otherwise then. However, since legends are placed at the very top of the fieldset (and thus ignores top border and padding), it's kind of strange that top border and padding are included in the containing block size when resolving percentages.

Anyway, my post about containing block size calculation concerns was written under the assumption that we really let the legend be part of the border area (that's what the current spec changes in this pull request say), but I believe this is something we still need to discuss.

I was quite sold on the "two boxes" approach myself, but then I noticed that WebKit just puts it in the border area (and expands the border area if necessary), which seems simpler, and also easy to reason about. Blink doesn't use two boxes for tables, like the spec says (that implementation detail isn't leaked via any web-exposed API that I'm aware of, though), but what I find tricky with this approach is to determine which properties should be set on the outer box and which to set on the inner one. https://www.w3.org/TR/CSS22/tables.html#model mentions 'position', 'float', 'margin-*', 'top', 'right', 'bottom', and 'left' as properties to set on the wrapper box. That list is far from complete, though. First of all, it only covers CSS 2 (and even then it seems to forget about things like z-index). How do you determine which property goes where?

EDIT: Looks like the answer to that lies in https://dxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css

mstensho commented Aug 21, 2018

Yes, all browsers render the same with my test, and I do agree that it's risky to spec it otherwise then. However, since legends are placed at the very top of the fieldset (and thus ignores top border and padding), it's kind of strange that top border and padding are included in the containing block size when resolving percentages.

Anyway, my post about containing block size calculation concerns was written under the assumption that we really let the legend be part of the border area (that's what the current spec changes in this pull request say), but I believe this is something we still need to discuss.

I was quite sold on the "two boxes" approach myself, but then I noticed that WebKit just puts it in the border area (and expands the border area if necessary), which seems simpler, and also easy to reason about. Blink doesn't use two boxes for tables, like the spec says (that implementation detail isn't leaked via any web-exposed API that I'm aware of, though), but what I find tricky with this approach is to determine which properties should be set on the outer box and which to set on the inner one. https://www.w3.org/TR/CSS22/tables.html#model mentions 'position', 'float', 'margin-*', 'top', 'right', 'bottom', and 'left' as properties to set on the wrapper box. That list is far from complete, though. First of all, it only covers CSS 2 (and even then it seems to forget about things like z-index). How do you determine which property goes where?

EDIT: Looks like the answer to that lies in https://dxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan
Member

zcorpan commented Aug 22, 2018

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Aug 22, 2018

Member

I find 20 pages in httparchive that style legend with a percentage height.

https://gist.github.com/zcorpan/186444076d75b735e99439bcddf92e40

Member

zcorpan commented Aug 22, 2018

I find 20 pages in httparchive that style legend with a percentage height.

https://gist.github.com/zcorpan/186444076d75b735e99439bcddf92e40

Show outdated Hide outdated source
@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Aug 23, 2018

Member

Here's a demo with percentage heights: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6143

A is 150px in Safari/Chrome/Firefox/Edge. B is 5px in Safari/Firefox, 150px in Chrome/Edge.

Member

zcorpan commented Aug 23, 2018

Here's a demo with percentage heights: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6143

A is 150px in Safari/Chrome/Firefox/Edge. B is 5px in Safari/Firefox, 150px in Chrome/Edge.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Aug 23, 2018

The B result in Firefox seems like a bug to me. I think it should be 150px. I filed bug 1485646.

MatsPalmgren commented Aug 23, 2018

The B result in Firefox seems like a bug to me. I think it should be 150px. I filed bug 1485646.

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Aug 23, 2018

Member

In that case, I think what https://drafts.csswg.org/css2/visudet.html#containing-block-details says should just apply to fieldset, without HTML having to say anything in particular. Right?

Member

zcorpan commented Aug 23, 2018

In that case, I think what https://drafts.csswg.org/css2/visudet.html#containing-block-details says should just apply to fieldset, without HTML having to say anything in particular. Right?

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Aug 23, 2018

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Aug 23, 2018

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Aug 24, 2018

@mstensho

This comment has been minimized.

Show comment
Hide comment
@mstensho

mstensho Aug 26, 2018

I'd like us to settle on a FIELDSET/LEGEND layout model.

<!DOCTYPE html>
<div style="width:400px; height:400px;">
  <fieldset style="overflow:scroll; padding:10%; width:100px; height:100px;">
    <legend>legend</legend>
    <div style="height:500px;">contents</div>
  </fieldset>
</div>

In this example we have a scrollable fieldset. The legend is not expected to scroll along with the fieldset contents, according to Firefox, Safari, and common sense.

This does suggest that it makes sense to create an anonymous child for the actual contents of the fieldset. So I'd like to explore that approach a bit further (rather than my former favorite: slap the legend in the border area, expand the border as necessary, paint it as part of border painting - like WebKit).

The question then is, which properties should the anonymous child inherit, and which ones should the parent fieldset ignore (if any). And how much magic do we have to apply in addition to that?

Intuitively, 'overflow' should go on the anoymous child, so that the legend isn't scrolled along with the rest. Padding probably needs to be ignored on the parent FIELDSET and be applied on the anonymous child, though, so that the scrollport includes the padding. However, percentages need to be resolved on the FIELDSET and NOT on the anonymous child. @MatsPalmgren Does Firefox really get away with no special magic here?

Firefox has a nice selector for the anonymous child here: https://dxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css

mstensho commented Aug 26, 2018

I'd like us to settle on a FIELDSET/LEGEND layout model.

<!DOCTYPE html>
<div style="width:400px; height:400px;">
  <fieldset style="overflow:scroll; padding:10%; width:100px; height:100px;">
    <legend>legend</legend>
    <div style="height:500px;">contents</div>
  </fieldset>
</div>

In this example we have a scrollable fieldset. The legend is not expected to scroll along with the fieldset contents, according to Firefox, Safari, and common sense.

This does suggest that it makes sense to create an anonymous child for the actual contents of the fieldset. So I'd like to explore that approach a bit further (rather than my former favorite: slap the legend in the border area, expand the border as necessary, paint it as part of border painting - like WebKit).

The question then is, which properties should the anonymous child inherit, and which ones should the parent fieldset ignore (if any). And how much magic do we have to apply in addition to that?

Intuitively, 'overflow' should go on the anoymous child, so that the legend isn't scrolled along with the rest. Padding probably needs to be ignored on the parent FIELDSET and be applied on the anonymous child, though, so that the scrollport includes the padding. However, percentages need to be resolved on the FIELDSET and NOT on the anonymous child. @MatsPalmgren Does Firefox really get away with no special magic here?

Firefox has a nice selector for the anonymous child here: https://dxr.mozilla.org/mozilla-central/source/layout/style/res/forms.css

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Aug 27, 2018

Member

Why doesn't the WebKit approach work when there is a scrollport? What does WebKit do in that case?

Member

zcorpan commented Aug 27, 2018

Why doesn't the WebKit approach work when there is a scrollport? What does WebKit do in that case?

Show outdated Hide outdated source
Show resolved Hide resolved source

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Sep 18, 2018

Bug 1491271 [wpt PR 13004] - HTML: test that a legend with negative l…
…eft margin masks the border, a=testonly

Automatic update from web-platform-testsHTML: test that a legend with negative left margin masks the border

See whatwg/html#3934

--

wpt-commits: e241e4de1c07c47f004199fc12d031559208b922
wpt-pr: 13004


--HG--
rename : testing/web-platform/tests/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements/fieldset-border-gap-ref.html => testing/web-platform/tests/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements/fieldset-border-gap-position-relative-ref.html

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Sep 18, 2018

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Sep 18, 2018

Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
Show outdated Hide outdated source
<ul>
<li>
<p>The <span>'display'</span> property is expected to act as follows:</p>

This comment has been minimized.

@bzbarsky

bzbarsky Sep 18, 2018

Collaborator

Again, not sure whether this should just explicitly set the used value.

@bzbarsky

bzbarsky Sep 18, 2018

Collaborator

Again, not sure whether this should just explicitly set the used value.

This comment has been minimized.

@zcorpan

zcorpan Sep 18, 2018

Member

There is no observable difference, is there?

@zcorpan

zcorpan Sep 18, 2018

Member

There is no observable difference, is there?

This comment has been minimized.

@zcorpan

zcorpan Sep 18, 2018

Member

I've changed this now.

@zcorpan

zcorpan Sep 18, 2018

Member

I've changed this now.

This comment has been minimized.

@bzbarsky

bzbarsky Sep 19, 2018

Collaborator

I guess it's not really clear to me what "act as" means if the used value is not being changed is all.

@bzbarsky

bzbarsky Sep 19, 2018

Collaborator

I guess it's not really clear to me what "act as" means if the used value is not being changed is all.

zcorpan added some commits Sep 18, 2018

painted behind the rectangle defined as follows, using the writing mode of the fieldset:</p>
<ol>
<li><p>The block-start edge of the rectangle is the smaller of the block-start edge of the

This comment has been minimized.

@mstensho

mstensho Sep 18, 2018

Should use the margin box of the legend, not the border box, as I've pointed out in another review issue (which seems to have disappeared now). But I guess that can be dealt with later.

@mstensho

mstensho Sep 18, 2018

Should use the margin box of the legend, not the border box, as I've pointed out in another review issue (which seems to have disappeared now). But I guess that can be dealt with later.

This comment has been minimized.

@zcorpan

zcorpan Sep 18, 2018

Member

Oops, sorry, fixed.

@zcorpan

zcorpan Sep 18, 2018

Member

Oops, sorry, fixed.

jankeromnes pushed a commit to jankeromnes/gecko that referenced this pull request Sep 19, 2018

Bug 1491271 [wpt PR 13004] - HTML: test that a legend with negative l…
…eft margin masks the border, a=testonly

Automatic update from web-platform-testsHTML: test that a legend with negative left margin masks the border

See whatwg/html#3934

--

wpt-commits: e241e4de1c07c47f004199fc12d031559208b922
wpt-pr: 13004
@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Sep 19, 2018

Member

@zcorpan I'm happy to land this, but it'd help if you could leave a suggested commit message as a comment. It should probably also mention the location all of the tests are in.

I know that browser bugs have been filed and multiple implementers are on board, so this is good to go otherwise.

Member

annevk commented Sep 19, 2018

@zcorpan I'm happy to land this, but it'd help if you could leave a suggested commit message as a comment. It should probably also mention the location all of the tests are in.

I know that browser bugs have been filed and multiple implementers are on board, so this is good to go otherwise.

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 19, 2018

Member
Revamp how fieldset and legend rendering is defined

Properly define the rendering of the fieldset and legend elements.

The layout model used is most similar to Gecko, which uses an anonymous box to hold the fieldset's contents.

Fixes #3955, fixes #3930, fixes #3929, fixes #3928, fixes #3927, fixes #3915, fixes #3913, fixes #3660, fixes #3331, fixes #2756, fixes #4013.

Tests:
https://github.com/web-platform-tests/wpt/tree/master/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements
https://github.com/web-platform-tests/wpt/tree/master/html/semantics/forms/the-fieldset-element
Member

zcorpan commented Sep 19, 2018

Revamp how fieldset and legend rendering is defined

Properly define the rendering of the fieldset and legend elements.

The layout model used is most similar to Gecko, which uses an anonymous box to hold the fieldset's contents.

Fixes #3955, fixes #3930, fixes #3929, fixes #3928, fixes #3927, fixes #3915, fixes #3913, fixes #3660, fixes #3331, fixes #2756, fixes #4013.

Tests:
https://github.com/web-platform-tests/wpt/tree/master/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements
https://github.com/web-platform-tests/wpt/tree/master/html/semantics/forms/the-fieldset-element

@zcorpan zcorpan merged commit 6fbb7ff into master Sep 19, 2018

2 checks passed

Participation zcorpan participates on behalf of Bocoup LLC
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@zcorpan zcorpan deleted the zcorpan/fieldset-revamp branch Sep 19, 2018

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Sep 20, 2018

Bug 1491985 [wpt PR 13040] - HTML: Test block margins on legend, a=te…
…stonly

Automatic update from web-platform-testsHTML: Test block margins on legend

See whatwg/html#3934

--

wpt-commits: e40235366bbd17f42e23e0177352c5f52c655909
wpt-pr: 13040

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Sep 20, 2018

Bug 1490645 [wpt PR 12965] - HTML: legend align maps to 'justify-self…
…', a=testonly

Automatic update from web-platform-testsHTML: legend align maps to 'justify-self'

See
whatwg/html#3934
whatwg/html#4013
--

wpt-commits: 51ceab16ec539fd421322727f93a847f7855e317
wpt-pr: 12965

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Sep 20, 2018

Bug 1490056 [wpt PR 12932] - HTML: test rendering of legend with diff…
…erent display values, a=testonly

Automatic update from web-platform-testsHTML: test rendering of legend with different display values

See whatwg/html#3934
--

wpt-commits: a0d4be661b5c006fe64b42fe08aeb992668052ac
wpt-pr: 12932

xeonchen pushed a commit to xeonchen/gecko that referenced this pull request Sep 20, 2018

Bug 1491985 [wpt PR 13040] - HTML: Test block margins on legend, a=te…
…stonly

Automatic update from web-platform-testsHTML: Test block margins on legend

See whatwg/html#3934

--

wpt-commits: e40235366bbd17f42e23e0177352c5f52c655909
wpt-pr: 13040

xeonchen pushed a commit to xeonchen/gecko that referenced this pull request Sep 20, 2018

Bug 1490645 [wpt PR 12965] - HTML: legend align maps to 'justify-self…
…', a=testonly

Automatic update from web-platform-testsHTML: legend align maps to 'justify-self'

See
whatwg/html#3934
whatwg/html#4013
--

wpt-commits: 51ceab16ec539fd421322727f93a847f7855e317
wpt-pr: 12965

xeonchen pushed a commit to xeonchen/gecko that referenced this pull request Sep 20, 2018

Bug 1490056 [wpt PR 12932] - HTML: test rendering of legend with diff…
…erent display values, a=testonly

Automatic update from web-platform-testsHTML: test rendering of legend with different display values

See whatwg/html#3934
--

wpt-commits: a0d4be661b5c006fe64b42fe08aeb992668052ac
wpt-pr: 12932

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Sep 24, 2018

Bug 1490022 [wpt PR 12930] - HTML: test fieldset percentage block siz…
…e, a=testonly

Automatic update from web-platform-testsHTML: test fieldset percentage block size

See whatwg/html#3934
--

wpt-commits: c4998afb119a14386c5645e0d1a7c90954849dab
wpt-pr: 12930

xeonchen pushed a commit to xeonchen/gecko that referenced this pull request Sep 25, 2018

Bug 1490022 [wpt PR 12930] - HTML: test fieldset percentage block siz…
…e, a=testonly

Automatic update from web-platform-testsHTML: test fieldset percentage block size

See whatwg/html#3934
--

wpt-commits: c4998afb119a14386c5645e0d1a7c90954849dab
wpt-pr: 12930

aarongable pushed a commit to chromium/chromium that referenced this pull request Sep 25, 2018

[LayoutNG] Fieldset layout algorithm.
This implements the basics for a layout algorithm for the FIELDSET
element. It doesn't yet contain min/max calculation, legend inline
alignment, or block fragmentation support. Nor do we attempt to
paint/hit-test/etc anything correctly. Painting is likely to require
some rather persuasive code on the legacy side, especially if we want to
get paint layers right (for scrolling or e.g. relatively positioned
legends).

This new implementation is not enabled by default, but can be enabled
via the (new) LayoutNGFieldset runtime flag.

There has been some recent spec work for FIELDSET / LEGEND [1], and we
aim to accommodate for all of that. Among other things it's been decided
that a fieldset may be a flex or grid container. We are also expected to
support multicol and scrollable containers. None of these things are
supported by legacy layout.

The NG implementation is designed to handle all of that (although, with
this CL, it handles none of them). This is the reason why we need an
anonymous fieldset content wrapper child, which contains all the
fieldset contents. The rendered legend is placed on the outside of that.
This is both for convenience reasons and pure necessity.

Necessity: The legend is expected NOT to scroll together with the
contents if the fieldset is scrollable. That'd obviously look silly.

Conveniece: Taking the legend out from the fieldset contents means that
none of the other layout algorithms (block layout, multicol, flex, grid)
need to support legends in their own peculiar ways.

A fieldset element generates a fragment with up to two child fragments;
first the rendered legend (if any), then the fieldset content (if any).

Given this markup:

<fieldset>
  <legend>leder</legend>
  <div>hosen</div>
</fieldset

The fragment tree will look like this:

                     +--------------------+
                     | Fieldset container |
                     | (FIELDSET DOM node)|
                     +--------------------+
                       /                \
                      /                  \
   +--------------------------+   +-------------------+
   | Fieldset content wrapper |   | Rendered legend   |
   |         (anonymous)      |   | (LEGEND DOM node) |
   +--------------------------+   +-------------------+
                |                          |
                |                          |
             +-----+                   +-------+
             | DIV |                   | leder |
             +++++++                   +-------+
                |
                |
            +-------+
            | hosen |
            +-------+

The fieldset content wrapper can be a regular block container, or,
eventually, a scrollable container, a multicol container, a flex
container, or a grid container. Fieldset padding is applied on the
anonymous wrapper, NOT on the fieldset container. The reason for this is
that padding is on the inside of the scrollport (if any), so since the
wrapper establishes the scrollport (in order to exclude the legend; we
don't want it to scroll with the rest), the padding needs to go there as
well. At the same time, the legend needs to take fieldset padding into
consideration, so some extra code is required for this.

[1] whatwg/html#3934

Bug: 875235
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: If952215459016e8528b2d94b74bca1c76e2fb4d6
Reviewed-on: https://chromium-review.googlesource.com/1236221
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594032}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment