Closed Bug 361693 Opened 18 years ago Closed 8 years ago

nested table doesn't resize correctly when sibling cell of parent table is dynamically resized

Categories

(Core :: Layout: Tables, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mozdev, Unassigned)

Details

(Keywords: regression, testcase)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061023 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061023 Firefox/1.5.0.7

When you click on "Short Layer", then "Tall Layer", then "Short Layer" again, the cell/table on the right doesn't resize again. It will however resize if you click on the heading of the expanded section, like after the above steps, clicking on "Short Layer" again will collapse it, and the cell on the right will resize back to normal.

To make it even worse, visiting http://www.antisocial.co.za/broken/noresize3.html you will see that removing the space between "Tall Layer", resulting in "TallLayer" causes the cell to never collapse again, and the resizing to be a bit screwy over all.

I tried this on Windows Firefox 2.0, and the same problem happened there. Playing with the HTML, sometimes the cell would resize but the table wouldn't, but clicking on it AGAIN to collapse it, or opening it from a state where all of them are collapsed, will make it resize fine.

The problems mostly occur when having them expand/collapse while another option is already expanded.

A bypass/hack that makes it work, is to first make the table/cell the original size it was in the beginning, and then fill up the layer.

I also noticed that if you use setTimeout to delay some of the javascript that fills the layers, it will work fine.

Reproducible: Always

Steps to Reproduce:
1. Click "Short Layer", section expands
2. Click "Tall Layer", "Short Layer" collapses, and "Tall Layer" section expands
3. Click "Short Layer", "Short Layer" expands

Actual Results:  
"Tall Layer" collapses but the size of the cell/table on the right remains unchanged.

Expected Results:  
For the cell/table on the right to resize in the same way, as when you clicked "Short Layer" initially.


I cleaned up the HTML quite a bit. If you can't reproduce, try the mostly original one at http://www.antisocial.co.za/broken/noresize2.html. 

In the above url in Firefox 2.0, the problem disappeared when I removed the "One Line" lines at the top, or the "Login Stuff" / "Links" lines. Basically if the sections that cause the problems appeared more to the top, the problem wasn't there.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061124 Minefield/3.0a1 ID:2006112404 [cairo]
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061123 Minefield/3.0a1 [reflow branch]
I also see this problem.
Keywords: testcase
This seems to get worse in the reflow branch builds, where the cell/table on the right never shrinks anymore.
I resurrect this old bug, because the testcase is working fine in Fx 3.0, but buggy in 3.1 b3 and on trunk.

When clicking on any of the two links twice, the table doesn't resize back to its original size.

On trunk, but not on Fx 3.1b3 this can be fixed by selecting some text in the red cell.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Summary: Cell and table within cell doesnt resize with the cell when filling/clearing layers in neighbouring cell → nested table doesn't resize correctly when sibling cell of parent table is dynamically resized
(In reply to comment #4)

works:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080907032646 Minefield/3.1b1pre ID:20080907032646
fails:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080908091724 Minefield/3.1b1pre ID:20080908091724

=> range:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-07+02%3A30&enddate=2008-09-08+09%3A17
This bug has been tagged for regression and/or closure.
Error is not appearing in Nightly or latest Release.
Version 	49.0a1
Build ID 	20160517030211
Version 	46.0.1
Build ID 	20160502172042
Considering this, I will mark this as Resolved-WFM
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: