textarea css height property conflicts with table height property

RESOLVED WORKSFORME

Status

()

Core
Layout
RESOLVED WORKSFORME
11 years ago
11 years ago

People

(Reporter: peter celine, Unassigned)

Tracking

1.8 Branch
x86
Windows XP
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

When we define a table with a height attribute set to 100%, and in that table some textareas that have the style height property also set to 100%, only the first textarea fills the cell. The others keep the default height.

Please see the attached code in the 'Steps to Reproduce' section.

Reproducible: Always

Steps to Reproduce:
1. Launch the html code beneath :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Test height</title>
</head>
<body>
<table height="100%">
<tbody>
<tr>
<td><b>1</b></td>
<td><textarea style="height:100%;overflow:auto;">This one fills the cell properly, as asked in the test.css stylesheet.</textarea></td>
</tr>

<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>

<tr>
<td><b>2</b></td>
<td><textarea style="height:100%;overflow:auto;">This one is shrinked, like the height property in the css would not have been taken in account.</textarea></td>
</tr>

<tr>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>

<tr>
<td><b>3</b></td>
<td><textarea style="height:100%;overflow:auto;">Same as with 2.
But overflow:auto seems activ...</textarea></td>
</tr>
</tbody>
</table>
</body>
</html>

Actual Results:  
The first textarea fills the cell, the others don't.

Expected Results:  
All textareas should have the height of their cell.

This was tested without any extension activ.
Under Internet Explorer, this code IS working.

Updated

11 years ago
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch

Comment 1

11 years ago
Created attachment 268982 [details]
Reporter's testcase

Note that it makes things a little easier to look if you attach HTML rather than pasting it into a comment.

Comment 2

11 years ago
Resolving WORKSFORME because this testcase is working as expected in a current development build (i.e. this will be working in FF 3.0).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

11 years ago
(In reply to comment #1)
> Created an attachment (id=268982) [details]
> Reporter's testcase
> 
> Note that it makes things a little easier to look if you attach HTML rather
> than pasting it into a comment.
> 

(In reply to comment #1)
> Created an attachment (id=268982) [details]
> Reporter's testcase
> 
> Note that it makes things a little easier to look if you attach HTML rather
> than pasting it into a comment.
> 


Sorry, I have tried to attach HTML, but there was no way to do it in the bug report formular...
(Reporter)

Comment 4

11 years ago
(In reply to comment #2)
> Resolving WORKSFORME because this testcase is working as expected in a current
> development build (i.e. this will be working in FF 3.0).
> 

The problem is that FF 3.0 isn't available at this moment. Could you please test it for FF 2.0?

Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 5

11 years ago
Re-resolving.  Bug resolutions track status on the trunk, not in the latest released version.  Development builds are available from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (although you probably want to back up your profile before trying one; see http://kb.mozillazine.org/Firefox_:_Tips_:_Backup).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 6

11 years ago
Thank you for the additionnal information, but migrating to Firefox 3.0 is not an option in our company :( 
If I understand you well, all Bug Reports affect the development branch. Is there no way to deliver a Bug Report for a Released version ?...

Comment 7

11 years ago
The issue is that even if you could somehow open a bug report against a release version, nobody would work on it... outside of critical bugs (i.e. security bugs and crashes), patches don't get checked into release branches because of the risk of regressions.
You need to log in before you can comment on or make changes to this bug.