Percent height border-box content should get correct height in percent height cells

Percent height border-box content should get correct height in percent height cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height. This is covered specifically in input-radio-height-inside-auto-container.html.
  It can also be seen in the updates to table-percent-height.html.

- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010
Committed: https://crrev.com/6c6315ec5c5ca31be742ebbe13cfecb43baae21a
Cr-Commit-Position: refs/heads/master@{#438652}

[rhogan, 2016-11-30 22:45:07]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-11-30 22:45:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-30 23:45:41]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-30 23:45:42]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[rhogan, 2016-12-02 18:52:35]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-02 18:53:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-02 20:55:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-02 20:55:06]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[rhogan, 2016-12-03 11:41:24]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-03 11:41:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-03 13:04:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-03 13:04:41]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[rhogan, 2016-12-03 18:10:39]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-03 18:10:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-03 19:30:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-03 19:30:11]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[rhogan, 2016-12-04 13:22:00]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-04 13:22:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-04 14:57:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-04 14:57:47]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[rhogan, 2016-12-04 21:46:19]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-04 21:46:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-04 23:17:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-04 23:17:21]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[rhogan, 2016-12-12 19:20:24]

Description was changed from

==========
Percent height border-box content should get correct height in percent height
cells

BUG=669867
==========

to

==========
Percent height border-box content should get correct height in percent height
cells


BUG=669867, 671010
==========

[rhogan, 2016-12-12 19:22:08]

Description was changed from

==========
Percent height border-box content should get correct height in percent height
cells


BUG=669867, 671010
==========

to

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects.


BUG=669867, 671010
==========

[rhogan, 2016-12-12 19:29:46]

Description was changed from

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects.


BUG=669867, 671010
==========

to

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized.

BUG=669867, 671010
==========

[rhogan, 2016-12-12 19:35:01]

Description was changed from

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized.

BUG=669867, 671010
==========

to

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height.

- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests.

BUG=669867, 671010
==========

[rhogan, 2016-12-12 19:35:33]

Description was changed from

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height.

- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests.

BUG=669867, 671010
==========

to

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height.

- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010
==========

[rhogan, 2016-12-12 19:44:50]

Description was changed from

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height.

- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010
==========

to

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height. This is covered specifically in
input-radio-height-inside-auto-container.html.
  It can also be seen in the updates to table-percent-height.html.
  
- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010
==========

[rhogan, 2016-12-12 19:48:00]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-12 19:48:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[rhogan, 2016-12-12 19:50:11]

robhogan@gmail.com changed reviewers:
+ eae@chromium.org

[eae, 2016-12-12 19:55:19]

LGTM w/suggestion

https://codereview.chromium.org/2535173006/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2535173006/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:3195: bool treatAsReplaced =
node() && node()->isElementNode() &&
Could you add a comment (or update the one above) the mention the form
control/image element case?

[commit-bot: I haz the power, 2016-12-12 21:42:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-12 21:42:11]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[rhogan, 2016-12-13 22:04:32]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-13 22:05:17]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-14 00:19:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-14 00:19:40]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[rhogan, 2016-12-14 19:20:45]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-14 19:21:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-14 19:26:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-14 19:26:04]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[rhogan, 2016-12-14 19:43:29]

The CQ bit was checked by robhogan@gmail.com to run a CQ dry run

[commit-bot: I haz the power, 2016-12-14 19:44:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-14 21:24:34]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-14 21:24:36]

Dry run: This issue passed the CQ dry run.

[rhogan, 2016-12-14 22:24:31]

The CQ bit was checked by robhogan@gmail.com

[rhogan, 2016-12-14 22:24:31]

The patchset sent to the CQ was uploaded after l-g-t-m from eae@chromium.org
Link to the patchset: https://codereview.chromium.org/2535173006/#ps180001
(title: "bug 669867")

[commit-bot: I haz the power, 2016-12-14 22:25:10]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-14 22:30:51]

CQ is committing da patch.

Bot data: {"patchset_id": 180001, "attempt_start_ts": 1481754271204300,
"parent_rev": "7a66a6b9541a95bd0cc9bb25eda8675a7bd98ed8", "commit_rev":
"a9bedfa27c029cbd024820db012fe612a5127c35"}

[commit-bot: I haz the power, 2016-12-14 22:31:23]

Description was changed from

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height. This is covered specifically in
input-radio-height-inside-auto-container.html.
  It can also be seen in the updates to table-percent-height.html.
  
- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010
==========

to

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height. This is covered specifically in
input-radio-height-inside-auto-container.html.
  It can also be seen in the updates to table-percent-height.html.
  
- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010

Review-Url: https://codereview.chromium.org/2535173006
==========

[commit-bot: I haz the power, 2016-12-14 22:31:25]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2016-12-14 22:32:55]

Description was changed from

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height. This is covered specifically in
input-radio-height-inside-auto-container.html.
  It can also be seen in the updates to table-percent-height.html.
  
- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010

Review-Url: https://codereview.chromium.org/2535173006
==========

to

==========
Percent height border-box content should get correct height in percent height
cells

"For the purpose of calculating [the minimum height of a row],
descendants of table cells whose height depends on percentages
of their parent cell's height are considered to have an auto
height if they have overflow set to visible or hidden or if
they are replaced elements, and a 0px height if they have not."

This CL does two things re this rule:

- It ensures we respect it for replaced elements, including ones that aren't
  LayoutReplaced or isReplaced() objects. This is covered by the table-percent-
  height-* tests.
- It ensures we always obey it for hidden/visible overflow elements.

The CL also does two other things:

- If the cell doesn't have a specified height then treat it as auto for the
  purposes of calculating percent heights of its children. See bug
  671010 for the discussion that leads to this approach - soon to be specified
  we hope.
  Note that this results in the new behaviour of the form control elements in
  table-percent-height-* tests: they size as they would if they were in auto-
  sized <div>. Again, see bug 671010.
  We introduce a 'regression' in the behaviour of radio/select elements when
  percent-sized inside a cell that has no specified height - they now behave
  the same as radio/select elements when inside a div with auto height, they
  get a zero height. This is covered specifically in
input-radio-height-inside-auto-container.html.
  It can also be seen in the updates to table-percent-height.html.

- If we've computed the height of a cell's child using the height made available
  by the cell, then be sure to respect content-/border-sizing of the child. We
  were just assuming that children were always content-sized. These are covered
  by the percent-height-border-box-content-* tests and are the main fall-out
  in 669867.

BUG=669867, 671010

Committed: https://crrev.com/6c6315ec5c5ca31be742ebbe13cfecb43baae21a
Cr-Commit-Position: refs/heads/master@{#438652}
==========

[commit-bot: I haz the power, 2016-12-14 22:32:56]

Patchset 10 (id:??) landed as
https://crrev.com/6c6315ec5c5ca31be742ebbe13cfecb43baae21a
Cr-Commit-Position: refs/heads/master@{#438652}