INPUT text field: Fix a chopped editing text issue.

INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.  It's an alternative fix for crbug.com/519331 rather than
  crbug.com/576589.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  Before this change, if the inner-editor height was taller than the INPUT box
  height, we put the inner-editor element on the top edge of the INPUT box, and
  overrode its height to clip the text.
  Instead of it, we always center the inner-editor element vertically like
  Firefox does. Also, this change also removes the quirky behavior such that
  editing text poked INPUT padding and border.

BUG=576589, 461117, 361728
TEST=automated

Committed: https://crrev.com/3c65391ef8b927a5f72e77e3879076bd22a8f908
Cr-Commit-Position: refs/heads/master@{#369975}

[tkent, 2016-01-13 04:15:01]

Patchset #1 (id:1) has been deleted

[tkent, 2016-01-13 08:11:36]

Patchset #2 (id:40001) has been deleted

[tkent, 2016-01-13 08:11:50]

Patchset #1 (id:20001) has been deleted

[tkent, 2016-01-13 08:37:22]

Description was changed from

==========
INPUT text field: Ignore CSS line-height if CSS height is specified.

inner-editor element doesn't need to honor the specified line-height if the
INPUT elment has a concrete height.

BUG=576589
TEST=automated
==========

to

==========
INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough
space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  We put the inner-editor element on the top edge of the INPUT box, and overrode
  its height to clip the text. This change stops them.
  We always center the inner-editor element vertically like Firefox does.
  stops it, and 

BUG=576589
TEST=automated
==========

[tkent, 2016-01-13 08:50:57]

Description was changed from

==========
INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough
space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  We put the inner-editor element on the top edge of the INPUT box, and overrode
  its height to clip the text. This change stops them.
  We always center the inner-editor element vertically like Firefox does.
  stops it, and 

BUG=576589
TEST=automated
==========

to

==========
INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough
space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.  It's an alternative fix for crbug.com/519331 rather than
  crbug.com/576589.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  Before this change, if the inner-editor height was taller than the INPUT box
  height, we put the inner-editor element on the top edge of the INPUT box, and
  overrode its height to clip the text.
  Instead of it, we always center the inner-editor element vertically like
  Firefox does. Also, this change also removes the quirky behavior such that
  editing text poked INPUT padding and border.

BUG=576589
TEST=automated
==========

[tkent, 2016-01-13 08:52:46]

Description was changed from

==========
INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough
space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.  It's an alternative fix for crbug.com/519331 rather than
  crbug.com/576589.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  Before this change, if the inner-editor height was taller than the INPUT box
  height, we put the inner-editor element on the top edge of the INPUT box, and
  overrode its height to clip the text.
  Instead of it, we always center the inner-editor element vertically like
  Firefox does. Also, this change also removes the quirky behavior such that
  editing text poked INPUT padding and border.

BUG=576589
TEST=automated
==========

to

==========
INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough
space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.  It's an alternative fix for crbug.com/519331 rather than
  crbug.com/576589.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  Before this change, if the inner-editor height was taller than the INPUT box
  height, we put the inner-editor element on the top edge of the INPUT box, and
  overrode its height to clip the text.
  Instead of it, we always center the inner-editor element vertically like
  Firefox does. Also, this change also removes the quirky behavior such that
  editing text poked INPUT padding and border.

BUG=576589, 461117
TEST=automated
==========

[tkent, 2016-01-13 09:31:28]

tkent@chromium.org changed reviewers:
+ jchaffraix@chromium.org

[tkent, 2016-01-13 09:31:29]

jchaffraix, would you review this please?

- I don't land this before M49 branch.
- I'll try to remove the height hack for containerElement() after this CL.

[Julien - ping for review, 2016-01-14 16:46:18]

Glad to see a lot of this code removed. lgtm !

https://codereview.chromium.org/1584683002/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/forms/input-textarea-padding-match-expected.html
(right):

https://codereview.chromium.org/1584683002/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/forms/input-textarea-padding-match-expected.html:9:
font-size: 0px;
Why do we need those changes?

https://codereview.chromium.org/1584683002/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/forms/text/text-font-height-mismatch.html
(right):

https://codereview.chromium.org/1584683002/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/forms/text/text-font-height-mismatch.html:22:
'value="ふ ABCgjy">' +
In the new output, the value from this first <input> is now clipped. I am
assuming that this is expected as it is shifted a bit lower than before the
change.

[tkent, 2016-01-15 02:09:49]

https://codereview.chromium.org/1584683002/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/forms/input-textarea-padding-match-expected.html
(right):

https://codereview.chromium.org/1584683002/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/forms/input-textarea-padding-match-expected.html:9:
font-size: 0px;
On 2016/01/14 at 16:46:18, Julien - leaving Blink Jan 18 wrote:
> Why do we need those changes?

This test doesn't work with the LayoutTextControlSIngleLine change because we
change the behavior in a case of font-size is taller than the INPUT height
(align at the top vs. centering).

The purpose of this test is to ensure identical text position in INPUT and
TEXTAREA.  So, font-size:0px was a wrong fix.  I should remove 'height' property
of the INPUT instead.

https://codereview.chromium.org/1584683002/diff/60001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/forms/text/text-font-height-mismatch.html
(right):

https://codereview.chromium.org/1584683002/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/forms/text/text-font-height-mismatch.html:22:
'value="ふ ABCgjy">' +
On 2016/01/14 at 16:46:18, Julien - leaving Blink Jan 18 wrote:
> In the new output, the value from this first <input> is now clipped. I am
assuming that this is expected as it is shifted a bit lower than before the
change.

As for this INPUT, I think no pixel differences.  The clipped text in the third
INPUT is an expected behavior change because we clip text by content box.

[tkent, 2016-01-18 00:22:34]

Description was changed from

==========
INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough
space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.  It's an alternative fix for crbug.com/519331 rather than
  crbug.com/576589.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  Before this change, if the inner-editor height was taller than the INPUT box
  height, we put the inner-editor element on the top edge of the INPUT box, and
  overrode its height to clip the text.
  Instead of it, we always center the inner-editor element vertically like
  Firefox does. Also, this change also removes the quirky behavior such that
  editing text poked INPUT padding and border.

BUG=576589, 461117
TEST=automated
==========

to

==========
INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough
space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.  It's an alternative fix for crbug.com/519331 rather than
  crbug.com/576589.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  Before this change, if the inner-editor height was taller than the INPUT box
  height, we put the inner-editor element on the top edge of the INPUT box, and
  overrode its height to clip the text.
  Instead of it, we always center the inner-editor element vertically like
  Firefox does. Also, this change also removes the quirky behavior such that
  editing text poked INPUT padding and border.

BUG=576589, 461117, 361728
TEST=automated
==========

[tkent, 2016-01-18 01:18:54]

Patchset #2 (id:80001) has been deleted

[tkent, 2016-01-18 01:19:00]

The CQ bit was checked by tkent@chromium.org

[tkent, 2016-01-18 01:19:00]

The patchset sent to the CQ was uploaded after l-g-t-m from
jchaffraix@chromium.org
Link to the patchset: https://codereview.chromium.org/1584683002/#ps100001
(title: "Update input-textarea-padding-match.html")

[commit-bot: I haz the power, 2016-01-18 01:19:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1584683002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1584683002/100001

[commit-bot: I haz the power, 2016-01-18 01:45:48]

Committed patchset #2 (id:100001)

[commit-bot: I haz the power, 2016-01-18 01:46:51]

Description was changed from

==========
INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough
space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.  It's an alternative fix for crbug.com/519331 rather than
  crbug.com/576589.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  Before this change, if the inner-editor height was taller than the INPUT box
  height, we put the inner-editor element on the top edge of the INPUT box, and
  overrode its height to clip the text.
  Instead of it, we always center the inner-editor element vertically like
  Firefox does. Also, this change also removes the quirky behavior such that
  editing text poked INPUT padding and border.

BUG=576589, 461117, 361728
TEST=automated
==========

to

==========
INPUT text field: Fix a chopped editing text issue.

This CL fixes crbug.com/576589.  The editing text looked to be chopped because:
 - the selected font height is taller than the specified |line-height|.
 - the specified |height| is taller than the |line-height|.
 - So, the inner-editor element is shorter though the INPUT box has enough
space.

This CL fixes the problem by the following changes:

* Resetting CSS line-height if CSS height is specified.
  In such case line-height makes no sense, and we don't need to clip the
  inner-editor element with it.

  However, this change causes a regression for crbug.com/519331.  So we need
  the change below.  It's an alternative fix for crbug.com/519331 rather than
  crbug.com/576589.

* Always center the inner-editor element vertically regardless of its height,
  don't override the height, and clip editing text with controlClipRect().

  Before this change, if the inner-editor height was taller than the INPUT box
  height, we put the inner-editor element on the top edge of the INPUT box, and
  overrode its height to clip the text.
  Instead of it, we always center the inner-editor element vertically like
  Firefox does. Also, this change also removes the quirky behavior such that
  editing text poked INPUT padding and border.

BUG=576589, 461117, 361728
TEST=automated

Committed: https://crrev.com/3c65391ef8b927a5f72e77e3879076bd22a8f908
Cr-Commit-Position: refs/heads/master@{#369975}
==========

[commit-bot: I haz the power, 2016-01-18 01:46:52]

Patchset 2 (id:??) landed as
https://crrev.com/3c65391ef8b927a5f72e77e3879076bd22a8f908
Cr-Commit-Position: refs/heads/master@{#369975}