Closed Bug 385022 Opened 17 years ago Closed 17 years ago

textarea css height property conflicts with table height property

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: peter.celine, Unassigned)

Details

Attachments

(1 file)

Reporter's testcase
810 bytes, text/html
Details 
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.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
Attached file Reporter's testcase — 
Note that it makes things a little easier to look if you attach HTML rather than pasting it into a comment.
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
Closed: 17 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
(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...
(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 → ---
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
Closed: 17 years ago → 17 years ago
Resolution: --- → WORKSFORME
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 ?...
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.

Attachment

General

Creator:
Created:
Updated:
Size: