Closed Bug 1780444 Opened 2 years ago Closed 2 years ago

textarea with padding clips text at the padding edge, in the inline direction

Categories

(Core :: Layout: Form Controls, defect)

defect

Tracking

()

VERIFIED FIXED
104 Branch
Tracking Status
firefox104 --- verified

People

(Reporter: dholbert, Assigned: dholbert)

Details

Attachments

(6 files, 1 obsolete file)

STR:

  1. load attached testcase.

ACTUAL RESULTS:
The textarea clips the text at the inner edge of the padding-box (the outer edge of the content-box).

i.e. it looks like:

| [...padding...] Can y[...padding...]|

And there's a horizontal scrollbar to let you scroll the inside-the-padding area.

EXPECTED RESULTS:
Not sure it's specified anywhere; but for comparison, Blink and WebKit do not clip the text as eagerly as we do; they paint the text running into the padding area (or something like that), and the scrollbar lets you scroll to the end of the text (but no further). Maybe we should consider matching them, for interop purposes?

Conveniently, I think this would be a one-line UA-stylesheet tweak (though maybe there are side effects that we'd need to consider). If we style textareas with overflow-clip-box:padding-box (rather than the current[1] value padding-box content-box), then we seem to match Blink and WebKit.

[1] https://searchfox.org/mozilla-central/rev/ffb50da3ca89100b6ae5054cfe69c187679515f0/layout/style/res/forms.css#121

Attached file testcase 1
Attachment #9286293 - Attachment description: test.html → testcase 1

This testcase shows that our current behavior is consistent between textarea and input textfields.

Other browsers agree with us on input textfields (the lower part of this testcase) but disagree on textarea (as noted in comment 0).

Here's a screenshot showing testcase 2 in the various major browser engines.

I put a red box around the region that corresponds to the spot where we're non-interoperable right now (albeit internally consistent).

Firefox's behavior (on the testcases here) goes back at least as far as 2015-01-01. (Older builds are effectively the same as well, though they require prefixed -moz-box-sizing and have some other minor quirks).

It looks like we maybe used to have a similar issue in the block direction, but we fixed that last year in bug 1456052 (which is what hg blame on the forms.css line from comment 0 points to).

emilio, do you recall why we only changed the block-direction behavior there? (Maybe we just weren't aware at that point that we had this incompatibility in the inline direction?)

Before bug 1456052, we had overflow-clip-box: content-box. In bug 1456052, we changed the block axis value to be padding-box for compatibility on the testcase there; and this bug's testcase suggests we should do that for the inline axis as well (in other words, we should just remove the overflow-clip-box declaration and use the default value which is padding-box for both axes).

Flags: needinfo?(emilio)

A few more historical notes:

(In reply to Daniel Holbert [:dholbert] from comment #4)

Firefox's behavior (on the testcases here) goes back at least as far as 2015-01-01. (Older builds are effectively the same as well, though they require prefixed -moz-box-sizing and have some other minor quirks).

Before 2015-01-01, the most recent change that impacted behavior for the testcase here was bug 82711 where we added support for white-space to textareas -- which my testcase does take advantage of in order to create horizontal overflow. (Before that, the textarea's text just aggressively line-wraps here.)

Before that, the most recent change that impacted behavior on the testcase (specifically the <input> textfield) was bug 965237 and bug 971955:
https://hg.mozilla.org/mozilla-central/rev/6fb8bc793891#l3.3
Those gave us our current behavior for <input> textfields; before that, we'd let the text run right up to the right border-edge, regardless of any padding -- effectively matching what other browsers currently do for <textarea>. (Bug 965237 impacted input with explicit type="text"; bug 971955 made the same change for input textfields with unspecified type.)

Anyway, all of that is to say, it looks like:

  • our earlier changes in this area have been with an eye towards compat
  • and the older 2014-era work was around single-line textfields (input), with textarea changing for consistency
  • There was a reference to Google Translate (bug 961347) which was apparently dependent on us making textareas behave similarly.

Also: it turns out Chrome had a behavior-change between version 48 and 49. Version 48 (and earlier) renders my testcases' textareas with the text aggressively-linewrapping, to honor the padding. Version 49 (and later) renders my testcases' textareas the same way that current Chrome renders it (top-right of my comment 3 screenshot).

This all makes me tend to think we should drop the overflow-clip-box decl for textarea here, in the interests of compat.

Assignee: nobody → dholbert
Attachment #9286308 - Attachment description: WIP: Bug 1780444: Use the default "overflow-clip-box" value ("padding-box") on textarea, to match other browsers on not-clipping overly-long lines at the content/padding box threshold. r?emilio → Bug 1780444 part 1: Use the default "overflow-clip-box" value ("padding-box") on textarea, to match other browsers on not-clipping overly-long lines at the content/padding box threshold. r?emilio
Status: NEW → ASSIGNED

I don't think this behavior is spelled out in the spec, but it seems to the
consensus behavior among browsers at this point. Hence, I'm adding this as a
".tentative" testcase, due to the lack of authoritative spec-text here.

I'll add tests for additional writing-modes (for padding-inline-end) in a
subsequent patch in this series. I'll also add block-axis equivalents of these
tests in a subsequent patch.

Depends on D152309

This patch was generated automatically (based off of neighboring tests), using
the following bash script (executed in the "the-textarea-element" diretory):

for inlineVer in ./textarea-padding-i*; do
  blockVer=`echo $inlineVer | sed "s/padding-i/padding-b/"`
  hg cp $inlineVer $blockVer
  sed -i s/inline/block/g $blockVer
done

Depends on D152331

Flags: needinfo?(emilio)
Attachment #9286337 - Attachment is obsolete: true
Attachment #9286338 - Attachment description: Bug 1780444 part 4: Add block-axis variants of textarea text-in-padding tests, to validate that text can render in block-end padding but not block-start. r?emilio → Bug 1780444 part 3: Add block-axis variants of textarea text-in-padding tests, to validate that text can render in block-end padding but not block-start padding. r?emilio

First try run suggests that the change is shippable (no test failures besides intermittents).

Here's another Try run with the updated versions of the WPT tests, to be sure they pass everywhere:
https://treeherder.mozilla.org/jobs?repo=try&revision=87d54ddeffd1214f3fb15a41782e79d15bac5d6c

Pushed by dholbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/48f6e8c681da
part 1: Use the default "overflow-clip-box" value ("padding-box") on textarea, to match other browsers on not-clipping overly-long lines at the content/padding box threshold. r=emilio
https://hg.mozilla.org/integration/autoland/rev/a72984b399f7
part 2: Add tests to ensure that text can be rendered in a textbox's inline-end padding area, but not in its inline-start padding area. r=emilio
https://hg.mozilla.org/integration/autoland/rev/fb5353c55f7a
part 3: Add block-axis variants of textarea text-in-padding tests, to validate that text can render in block-end padding but not block-start padding. r=emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34929 for changes under testing/web-platform/tests
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch
Upstream PR merged by moz-wptsync-bot
QA Whiteboard: [qa-104b-p2]

I was able to reproduce this issue on Firefox 103.0(build ID: 20220718155818) on Ubuntu 22.04 using the testcase from Comment 1 and 2. Verified as fixed on Firefox 104.0(build ID: 20220818191623) and Nightly 106.0a1(build ID: 20220822190304) on Ubuntu 22.04, macOS 12 and Windows 10.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-104b-p2]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: