Closed Bug 1604086 Opened 4 years ago Closed 2 years ago

textarea doesn't expand to the full height of the parent when set in position: absolute

Categories

(Web Compatibility :: Site Reports, defect, P3)

Unspecified
Linux

Tracking

(Webcompat Priority:revisit, firefox88 affected)

RESOLVED INVALID
Webcompat Priority revisit
Tracking Status
firefox88 --- affected

People

(Reporter: karlcow, Unassigned)

References

()

Details

(Keywords: webcompat:contact-ready)

Attachments

(2 files)

Attached image firefox-chrome
  1. With Firefox Nightly 73
  2. Go to https://jsondraft.com/4c/
  3. Click on JSON or schema tab

Expected:
View the full code.

Actual:
textarea is only two lines high (while in Chrome it takes the full height.)

Reduced test case:
https://codepen.io/webcompat/pen/dyPpBgB

<!doctype html>
<title>textarea size</title>
<style>
textarea {
    top: 0;
    bottom: 0;
    position: absolute;
    background-color: pink;
}
</style>
  <textarea name="" id=""></textarea>

It could be an error in Chromium too.

The priority flag is not set for this bug.
:TYLin, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(aethanyc)

For a non-replaced position:absolute element, if top:0, bottom:0, and height:auto, Firefox resolves the height as if it has height:100% per https://drafts.csswg.org/css-position-3/#abs-non-replaced-height:

  1. If height is auto, top and bottom are not auto, then solve for height.

But Firefox treats <textarea> as if it is a replaced element that has a intrinsic height in this respect, and resolve its height first per spec https://drafts.csswg.org/css-position-3/#abs-replaced-height

However, per html spec, <textarea> doesn't list explicitly in the replaced elements though...

Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(aethanyc)
Priority: -- → P3

I would consider a <textarea> a replaced element... It creates the same layout box as an <input type="text">.

I would consider a <textarea> a replaced element... It creates the same layout box as an <input type="text">.

Agree, if we treat <textarea> as a replace element, then our behavior makes sense.

Karl, for the original site, instead of relying on top:0 and bottom:0 to enlarge the position:absolute to 100% height, which has different behavior regarding whether the element is a replaced element or not. It is best to use something like top:0 and height: 100% for the desired behavior.

Component: Layout: Form Controls → Desktop
Priority: P3 → --
Product: Core → Web Compatibility
Version: 73 Branch → unspecified

It sounds like we consider our behavior correct then (or not worth changing). I'll send an email to support@jsondraft.com.

Severity: normal → S3
Webcompat Priority: ? → revisit
Priority: -- → P3

I was able to reproduce the initial issue.
https://prnt.sc/10i6o1p

The issue on Codepen.io does not seem to reproduce, I get the same textarea layout in Firefox as in Chrome.
https://prnt.sc/10i6ouq

Tested with:
Browser / Version: Firefox Nightly 88.0a1 (2021-03-09)
Operating System: Windows 10 Pro

Status: UNCONFIRMED → NEW
Ever confirmed: true

The page can not be reached using multiple devices, browsers and VPN connections.

Tested with:

Browser / Version: Firefox Release 100.0 (64-bit)/ Firefox Nightly 102.0a1 (2022-05-05) (64-bit) /Firefox Beta 101.0b3 (64-bit)/ Chrome Version Version 101.0.4951.54 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64
Operating System: Mac OSX Catalina 10.15.7
Operating System: Ubuntu 20.4 LTS x64

Closing this as INVALID.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: