{inc}Height not reculated correctly when form changes

RESOLVED FIXED

Status

()

Core
Layout: Tables
RESOLVED FIXED
15 years ago
11 years ago

People

(Reporter: Jing Lim, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---
Bug Flags:
blocking1.8b3 -
blocking1.8b5 -
wanted1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

Try this:

<form style="height:100%">
<table height=100% bgcolor=yellow>
<tr><td onclick="this.innerHTML='<br><br>'">Click here
<tr height=100%><td><textarea style="height:100%"></textarea>
<tr><td>Bottom
</table>
</form>

When you click on 'click here', the textarea isn't resized, so now the form
occupies more than 100% height. However, when you resize the window a bit,
everything then gets calculated correctly.

Reproducible: Always
Steps to Reproduce:
1. Display the html above
2. Click on the 'Click here' text.
3.

Actual Results:  
The textarea isn't resized, the "Bottom" text moves down.

Expected Results:  
The textarea should shrink, and the whole form occupies full window height.


When you change 'form' to 'div', everything works fine. Must be something to
do with the form tag.
> Must be something to do with the form tag.

In particular, the fact that it has margins... If you remove those, the behavior
is that same as for <div>.

This is a block incremental layout issue.
Component: Layout: Form Controls → Layout: Block and Inline
OS: Windows 2000 → All
QA Contact: core.layout.form-controls → core.layout.block-and-inline
Hardware: PC → All
Summary: Height not reculated correctly when form changes → {inc}Height not reculated correctly when form changes

Comment 2

14 years ago
Created attachment 160156 [details]
testcase

Next time, can you attach a file demonstrating the bug instead of posting it as
a comment? It makes it easier for everyone. Thanks.

Comment 3

14 years ago
Confirming on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3)
Gecko/20040904 Firefox/0.9.1+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase

Comment 4

13 years ago
Any chance this bug might be fixed for Gecko 1.8 ?
roc's the margin-meister...
This may in fact be a table bug.
Created attachment 184043 [details]
reduced testcase without margins

Yes, it is a table bug. This testcase doesn't use margins. Click and the table
will increase its height beyond the CSS specified height. If you shrink the
window until a vertical scrollbar appears, the table will revert to the correct
height.

It looks like a combination of
-- A table with CSS specified height
-- A 100%-height row containing a 100%-height DIV
-- Changing the height of another row

Comment 8

13 years ago
nominating for firefox 1.1 :-)
Flags: blocking1.8b3?
Flags: blocking-aviary1.1?
Component: Layout: Block and Inline → Layout: Tables
QA Contact: layout.block-and-inline → layout.tables

Comment 9

13 years ago
I think I have seen this before, I believe thats a structural problem with incr.
reflow on rows
https://bugzilla.mozilla.org/show_bug.cgi?id=242981#c6 

Comment 10

13 years ago
I'm working on an app that will have a lot of usage. It works well in IE but
this is one of the blocking problems in FF. Would be great to have this resolved
in 1.1!
Flags: blocking-aviary1.1? → blocking-aviary1.1+

Updated

13 years ago
Flags: blocking-aviary1.1+ → blocking-aviary1.1?

Updated

13 years ago
Flags: blocking1.8b4?
Flags: blocking1.8b3?
Flags: blocking1.8b3-

Updated

13 years ago
Flags: blocking-aviary1.1?

Updated

13 years ago
Flags: blocking1.8b4? → blocking1.8b4-
Behaviour of test cases doesn't seem to have changed between:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)
David, you've been in this code recently... any idea what's up here?
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]

Comment 13

11 years ago
nominating as we've been getting feedback from webapp devs that this is a common issue for them.
Flags: blocking1.9- → blocking1.9?
Actually, this got fixed by the checkin for bug 381507.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Depends on: 381507
Flags: blocking1.9?
Resolution: --- → FIXED
I added the tests to reftest.
Flags: in-testsuite+
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
You need to log in before you can comment on or make changes to this bug.