textarea with padding clips text at the padding edge, in the inline direction
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox104 | --- | verified |
People
(Reporter: dholbert, Assigned: dholbert)
Details
Attachments
(6 files, 1 obsolete file)
STR:
- 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.
Assignee | ||
Comment 1•2 years ago
|
||
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 2•2 years ago
|
||
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).
Assignee | ||
Comment 3•2 years ago
|
||
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).
Assignee | ||
Comment 4•2 years ago
•
|
||
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).
Assignee | ||
Comment 5•2 years ago
•
|
||
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
.)
Assignee | ||
Comment 6•2 years ago
|
||
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 | ||
Comment 7•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 8•2 years ago
|
||
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
Assignee | ||
Comment 9•2 years ago
|
||
Depends on D152330
Assignee | ||
Comment 10•2 years ago
•
|
||
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
Assignee | ||
Comment 11•2 years ago
|
||
Canceling needinfo, in favor of review-requests. :)
Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d5e30a7c84cd664d45e36d239be8f396d4690a6c
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 12•2 years ago
|
||
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
Comment 13•2 years ago
|
||
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
Comment 15•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/48f6e8c681da
https://hg.mozilla.org/mozilla-central/rev/a72984b399f7
https://hg.mozilla.org/mozilla-central/rev/fb5353c55f7a
Upstream PR merged by moz-wptsync-bot
Updated•2 years ago
|
Comment 17•2 years ago
|
||
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.
Description
•